По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.
В данной главе рассматриваются вопросы технической диагностики системы автоматического мониторинга ВОЛС, необходимость в которой возникает из-за сложности этой системы.
Техническое диагностирование - процесс определения технического состояния изделия с определенной точностью. Цель технического диагностирования это поддержание достаточного уровня надежности.
При наступлении отказа диагностирование предполагает обнаружение факта отказа и его локализацию. Система технического диагностирования (СТД) - совокупность средств, осуществляющих измерение количественных значений параметров (диагностических параметров ДП), анализ и обработку результатов измерений по установленным алгоритмам. Техническим средством диагностирования являются автоматические измерительные системы, рассмотренные в главе 2. Одним из основных методов решения задач диагностирования является моделирование объекта технического диагностирования и выделение взаимосвязей в этих моделях. Модель объекта - это формализованная сущность, характеризующая определенные свойства реального объекта в удобной и желательно для инженера в наглядной форме.
Существуют аналитические модели, в которых модель строится на основе уравнений, связывающих различные параметры; графоаналитические, основанные на представлении диаграмм (в частности направленных графов) прохождения сигналов; информационные модели представляют собой информационные описания в терминах энтропия, информация и т.п.
Чаще всего используемым в практических целях и наиболее наглядным являются функционально-логические модели, которые реализуются различными способами, определяемыми особенностью функциональной схемы диагностируемого изделия.
В настоящей работе применяется диагностирование, основанное на функционально-логическом моделировании и реализуемое инженерным способом. В соответствии с решаемой задачей выбирается та или иная "функция предпочтения". В данном случае решается задача поиска неисправности, для которой выбирается W4 функция предпочтения о которой ниже.
Разработка алгоритма диагностирования
Считаем, что объект диагностирования задан следующей функциональной схемой (рисунок 1).
После построения функциональной модели необходимо определить множество возможных состояний объекта, который диагностируется. Общее число состояний при N функциональных элементов при двоичных исходах проверок (1 исправно, 0 неисправно) равно при диагностировании системы 2N - 1. Предполагается, что одновременное появление двух независимых отказов маловероятно, поэтому число сочетаний из N элементов по одному, равно N. Число всех возможных различных состояний аппаратуры, которая диагностируется, одновременно с учетом отказов одного функционального - сводятся в таблицу состояний (матрицу исправностей, матрицу неисправностей и т. п.), которая используется при разработке программы (алгоритма) поиска неисправностей.
Матрица состояний строится по следующим правилам:
S0 - строка, соответствующая работоспособному состоянию;
Sj - строка, соответствующая состоянию в котором оказался j-тый элемент модели.
Например, состояние S4 = 0 означает событие, при котором отказал 4-ый четвертый элемент модели; S2 = 0- второй и т.п.). Этому событию соответствует недопустимое значение сигнала Zi, и тогда на пересечении пишется 0. Если любой другой i - й элемент также недопустимое значение Zi, то на пересечении j ой строки и Zi - ого столбца таким же образом записывается "0"; при этом, если значение параметра будет находиться в допуске, то на пересечении пишется "1". Считается, что значения всех внешних входных сигналов xi всегда будут находиться в пределах допуска, а линии связи между элементами абсолютно надежны. Если есть сомнение в надежности линии, то её принимают за функциональный элемент.
Транспонируем матрицу (таблица 1). Так как мы осуществляем построение алгоритма поиска неисправности, то первую строку S0, означающее исправное состояние исключаем. Последний столбец функция предпочтения W4, которую установили из следующих соображений.
Так как матрица заполнена нулями и единицами, то равенство некоторого ij элемента соответствует тому, отказ i-го элемента влияет на j-ый выходной параметр j-го элемента, если контролировать выходной параметр Zj можно определить, в каком именно состоянии находится i-ый элемент. Следовательно, чем больше "0" в строке Zj матрицы, тем более большое количество информации может нести этот параметр о состоянии объекта, который находится под контролем. Для этого в качестве предпочтительной функции решении данной задачи контроля работоспособности необходимо принимать функцию вида:
Где ;
- означает количество нулей в I-ой строке матрицы.
Если для объекта контроля известны вероятности состояний P(Zi):
Также заданы C(Zi) стоимости контроля параметров:
Так как строится алгоритм нахождения неисправности, то функция предпочтения будет:
где суммы означают количество нулей и единиц соответственно в I-той строке транспонированной матрицы состояний. Значения W4(Zi) для каждой строки приведены в последнем столбце транспонированной матрицы (таблица 3.2).
Последовательность решения следующая:
1) Выбираем ту строку, в которой функция предпочтения W4(Zi) минимальна, так как эта строка несет максимальное количество информации, разбивая все возможные состояния объекта на две равные части.
2) Минимально значение для 6,7,13 и 14 строк, т.е. по этому критерию они равнозначны. Для контроля выбираем строку 7. Итог контроля по этому параметру W4(Zi) разбивает матрицу на равные части W4(Z7) - первое разложение:
2.1) Эти состояния не влияют на данный выходной параметр функционального элемента;
2.2) Значения параметра не в допуске, что говорит о неисправности объекта.
3) Дальше аналогично анализируются обе получившиеся части (3-е, 4-е и последующие разложения (как показано на рисунке 6).
4) Процедура продолжается, пока множество N=14 возможных состояний объекта диагностирования не будут разделены на отдельные состояния.
Чтобы упорядочить для дальнейшего осколки введём следующее обозначение для каждого конкретного осколка:
Где m - номер разбиения;
"H" - принимает значение 1 или 0 в зависимости от состояния строки матрицы;
n - номер осколка, считая, что осколки всегда располагаются, начиная с "1".
Например, обозначение 3«0»6 значит, что это осколок при третьем разбиении для значения "0". (впрочем, "1" всегда соответствуют нечетные значения "n", а «0» - четные)
Ниже представлены результаты анализа для принятой конкретной функциональной модели на рисунке 3.
Первое разбиение по строке Z7, имеющая W7 = 0
z7, имеющая W7 = 0
В таблице 3.3. представлена матрица (осколок) после первого разбиения для результатов проверки «1», т.е. при введенных обозначениях: 1«1»1. Для второго разбиения взята строка Z11, имеющая меньшее значение функции предпочтения W4 = 1
В таблице 3.4 представлена таблица после первого разбиения с «0»,, т.е. 1«0»,1.
Дальше "заливкой" показаны строчки, выбранные для следующих разбиений.
Для первого разбиения матрицы взята строка Z11, функция предпочтения которой W4 = 1.
S8
S9
S10
S11
S12
S13
S14
W4
z8
0
1
1
1
1
1
1
5
z9
1
0
1
1
1
1
1
5
z10
1
1
0
1
1
1
1
5
z11
1
1
0
0
0
1
1
1
z12
1
1
0
0
0
1
1
1
z13
1
1
0
0
0
0
1
1
z14
1
1
0
0
0
1
0
1
Таблица 3. - 1«1»1
S1
S2
S3
S4
S5
S6
S7
W4
z1
0
1
1
1
1
1
1
5
z2
0
0
0
1
1
1
1
1
z3
1
1
0
1
1
1
1
1
z4
1
1
0
0
0
1
1
1
z5
1
1
0
0
0
1
1
3
z6
1
1
0
0
0
0
1
7
z7
1
1
0
0
0
1
0
7
Таблица 4. - 1«0»1
Матрица после второго разбиения при «1». Для 3-го разбиения взята строка Z13
Результаты третьего разбиения:
Результаты четвертого разбиения:
По результатам разбиений получаем номера ФБ для контроля:
результат третьего разбиения:
3«0»2→13;
3«1»4→11 и 12;
3«0»4→10;
3 «1»5→6 и 7;
3«0»6→5;
3 «1»7→4.
Результат четвертого разбиения:
4«0»2 → 9.
Результат пятого разбиения:
5«1»1 → 8;
5«0» →14;
5«1»15 → 2 и 3;
5«0»16 →1.
По полученным в результате анализа матрицы состояний номерам контролируемых ФБ для определения неисправного блока строим алгоритм контроля.
Алгоритм контроля
Рисунок 2. Как видно из алгоритма, максимальное количество элементарных проверок для нахождения неисправного ФБ равно 5 (в данном случае ФБ 8 и 14)
Заключение
1.На основе функционально-логической модели и инженерного способа разработан оптимальный алгоритм диагностирования гипотетической систем, которая моделирует систему автоматического контроля и мониторинга.
2. Проведен расчет и в результате получен алгоритм. Для принятой модели максимальное число элементарных испытаний равно 5.
Всем привет! В сегодняшней статье я покажу самый простой способ как заполучить себе маршрутизатор Mikrotik для опытов - например для подготовки к сертификации или просто для различных тестов. Вы спросите, как же это возможно? Ответ прост - за счет растущей популярности концепции NFV (Network Functions Virtualization - виртуализация сетевых функций). Вы можете просто скачать образ маршрутизатора и производить любые манипуляции. Ниже я опишу способ установки RouterOS на Hyper-V и VirtualBox.
Установка RouterOS на VirtualBox
Итак, начнем с VirtualBox - первым делом необходимо скачать .vdi образ жесткого диска, сделать это можно по ссылке https://mikrotik.com/download и найти .vdi образ нужной вам версии - я выбрал 6.38.7
Далее включаем VirtualBox и создаем новую виртуальную машину с характеристиками как на скриншотах ниже:
Далее нажимаем на кнопку Создать - и производим настройки сетевого интерфейса, который нужно установить в режим сетевого моста, как на скриншоте ниже:
Далее запускаем виртуальную машину. Процесс запуска займет некоторое время, далее вы получите возможность зайти в CLI вашего виртуального маршрутизатора. По умолчанию логин admin и пустой пароль.
Для того, чтобы понять какой адрес был выдан вашему виртуальному маршрутизатору - наберите команду:
ip addresses print
Важный момент - CLI у RouterOS очень удобен и поддерживает табуляцию (нажатие Tab для выполнения правильного написания команды). В итоге, вы должны получить следующий вывод:
Установка RouterOS на Hyper-V
Далее перейдем к процессу установки RouterOS образа на Hyper-V - он также прост, и, в общем и целом не отличается от такового на VirtualBox, но есть нюанс: необходимо скачать .vhdx образ, а не .vdi. После того как скачали образ, перейдем к процессу установки - вам необходимо установить параметры виртуальной машины также, как на скриншотах ниже:
Необходимо нажать на кнопку Finish и запустить виртуальную машину. После выполнения манипуляций, описанных выше, вы получаете адрес маршрутизатора, по которому вы можете попасть на маршрутизатор любым удобным вам способом - по SSH, через Web-интерфейс или же через программу Winbox. К примеру ниже на скриншоте изображен веб-интерфейс только что созданного виртуального маршрутизатора.
На этом все, в дальнейшем мы будем подробно освещать настройку виртуального маршрутизатора Mikrotik в наших статьях. Спасибо за внимание!