Данный документ не является полной инструкцией к действию. Он предназначен для общего понимания задачи развертывания сервера FM3 и организации сервиса под требуемые уровни надежности и масштабируемости.
Документ дает общее описание задач, конкретное выполнение которых должно производиться администраторами сервера.
Администратор должен хотя бы поверхностно быть знаком со следующим:
Развертывание серверов для FortMonitor 3
Всего можно выделить 4 основные части:
Для каждого сервера необходимо настроить синхронизацию времени.
Для серверов на ОС Windows рекомендуется настроить синхронизацию на обоих серверах с более частым интервалом, например – раз в 30 минут (по умолчанию синхронизация происходит раз в день). Как это сделать можно прочитать, например здесь.
Для серверов с ОС Linux рекомендуется установить NTPD.
Основные части могут быть развернуты как на одном сервере, так и на нескольких – в различных комбинациях:
В итоге полная структура сервиса может быть такой:
Репликация средствами БД настраивается отдельно. Для MySQL документации довольно много, поэтому ее настройка не должна вызвать серьезных затруднений.
Например, описание создания репликации без остановки основного сервера БД:
https://dba.stackexchange.com/questions/35977/mysq...
Снятие резервных копий может производиться каждый день с помощью планировщика задач или cron – в зависимости от ОС, на которой работает сервер БД.
При снятии копии с основного сервера часто возникает проблема, что копия не консистентна - н-р, при создании датчика во время снятия резервной копии процесс будет прерван, т.к. структура таблиц изменится.
Снятие копии с резервного сервера позволит избежать этой проблемы. Для этого потребуется остановить репликацию, снять копию и снова запустить репликацию.
Такой алгоритм позволит получить 100% консистентный файл резервной копии и снизить нагрузку на основной сервер.
Еще более сложной структурой может быть организация не одного экземпляра резервной БД, а нескольких. К примеру, можно организовать 3х-уровневую структуру:
Основной сервер > Горячий резерв > Холодный резерв.
Такая структура позволит при каких-то проблемах с основным сервером быстро переключиться на горячий резерв – при этом холодный резерв станет горячим. И при устранении проблем с бывшим основным сервером сделать из него холодный резерв.
Таким образом получим систему, позволяющую в самом плохом случае пережить отказ основного сервера и горячего резерва, оставшись работать на холодном резерве.
Также для обеспечения надежности приема данных возможно развертывание нескольких копий приемщиков данных. Один из них будет основным, другие – будут находиться в горячем резерве. Либо все они будут принимать данные от какой-то части терминалов.
За распределение нагрузки будет отвечать специальный программный или аппаратный комплекс маршрутизации и балансировки трафика на уровне L4. Он будет следить за доступностью приемщиков данных и направлять трафик к ним.
Конфигурация серверов
При развертывании любого сервера его жесткие диски необходимо организовать в RAID 1 (Зеркало) или более высокий. Это позволит увеличить быстродействие дисковой подсистемы и при выходе из строя одного из дисков заменить его без простоя сервера.
Выбор конфигурации в большой степени зависит от предполагаемой нагрузки на СМТ:
Приблизительная методика расчета требуемого места для БД.
Тип |
Размер, байты |
Навигационная часть |
100 |
Аналоговый датчик |
8 |
Дискретный датчик |
1 |
Датчик RFID |
8 |
Датчик топлива |
8 |
Предположим, что объект присылает данные в среднем 4 раза в минуту.
Помимо навигационной информации передается 4 аналоговых и 10 дискретных датчиков, и на основе аналогового датчика создан датчик топлива. Итого 1 пакет будет занимать:
100 + 4*8 + 10*1 + 1*8 = 150 байт.
Период |
Размер |
1 минута |
150*4 = 600 байт |
1 день |
600*60*24 = ~850 КБайт |
1 месяц |
850*30 = ~25 МБайт |
1 год |
25*12 = 300 МБайт |
На самом деле объем будет больше – т.к. информация на диске всегда фрагментирована, и плюс к этому необходимо место для хранения индексов в БД. Индексы в БД служат для ускорения поиска нужных данных и могут занимать место, сравнимое с объемом самих данных.
Учитывая эти нюансы, на хранение информации за 1 год по 1 объекту потребуется минимум 500 МБайт дискового пространства.
С учетом того, что идет постоянный рост количества передаваемой информации от терминалов (CAN-шина, дополнительное навесное оборудование и т.д.), то можно планировать 1-1.5 ГБайт на 1 объект за 1 год.
Внимание! Это размер только БД! Если конфигурация такова, что весь сервис располагается на одном сервере, необходимо учитывать место под остальные сервисы, в частности – данные, принятые от терминалов, различные логи – в том числе и системные.
Если в конфигурации серверов присутствует резервный сервер БД, то необходимо предусмотреть место для ведения бинарных логов. В идеале это должен быть отдельный жесткий диск для уменьшения нагрузки на основную дисковую подсистему.
Если БД и сервисы размещены на разных серверах, необходимо настраивать синхронизацию времени на этих серверах. Расхождение во времени в несколько секунд может привести к тому, что последнее местоположение объектов на карте может отображаться совсем не там, где на самом деле находятся эти объекты.
Причем для ОС Windows встроенная синхронизация не всегда работает корректно. Требуется изменение интервала синхронизации времени – уменьшение его до получаса или часа.
Оперативная память достаточно критична для работы БД. Идеальным считается вариант, когда вся БД помещается в оперативную память. В этом случае практически полностью снимается нагрузка на жесткие диски (за исключением нагрузки на запись) и уменьшается время отклика системы в целом.
Как правило, такого идеального варианта достигнуть не получается. Поэтому желательно, чтобы в память помещались хотя бы индексы БД – это обеспечит более быстрый поиск нужной информации и снизит чтение информации с диска.
Мониторинг серверов
Какой бы ни была конфигурация серверов, на каждом из них необходимо настраивать мониторинг основных параметров.
Для всех типов серверов всегда нужно контролировать следующие параметры:
Для сервера БД дополнительно можно контролировать состояние MySQL – количество запросов в секунду (select, insert, update), количество соединений к БД и т.д.
Для сервера IIS контролировать параметры IIS – количество запросов в секунду, количество установленных соединений, количество запросов в очереди, среднее время выполнения запроса и т.д.
Для особо критичных параметров необходимо настроить уведомления, по которым срочно нужно принимать меры.
К таким параметрам можно отнести:
Мониторинг данных параметров можно настроить с помощью любой системы мониторинга серверов – Nagios, Zabbix, Munin, Cacti и многие другие.
Также можно воспользоваться нашими услугами по мониторингу серверов, обратившись к менеджеру продукта.
Создание резервной копии БД
Настоятельно рекомендуется каждый день создавать резервную копию БД и хранить не менее 3 последних копий. Причем копии желательно хранить в отдельном хранилище – это повысит шанс сохранить хотя бы одну копию БД при проблемах с жесткими дисками.
Создание копии может производиться либо с использованием Планировщика задач (ОС Windows), либо через cron (ОС Linux), либо каким-то сторонним ПО для создания бэкапов MySQL.
Рекомендуется создавать копию средствами MySQL (mysqldump). Но также возможно создание копии посредством копирования LVM.
Если сервис развернут с резервным сервером БД, то резервную копию рекомендуется производить именно с этой резервной БД. Для этого нужно остановить репликацию, создать резервную копию и снова запустить репликацию.
При создании резервной копии рекомендуется производить архивирование “на лету”. Это позволит снизить нагрузку на дисковую подсистему при создании резервной копии, а также уменьшить место, занимаемое файлом резервной копии.
Пример создания резервной копии с помощью mysqldump:
mysqldump -uroot -h127.0.0.1 --default-character-set=utf8 --single-transaction -p1234 fm3base > "C:\backup.sql"
Создание с архивацией. Для этого должен быть установлен gzip.
mysqldump -h127.0.0.1 -uroot -p1234 --default-character-set=utf8 --single-transaction fm3base | gzip > "C:\backup.sql.gz"
Файлы, которые необходимо контролировать вручную
Контроль таблиц в БД
Конфигурация БД
В версиях MySQL ранее 5.6 в конфигурации параметр innodb_file_per_table выставлен в значение 0.
Это значит, что все базы и все таблицы в них хранятся в одном огромном файле ibdata1, который находится по умолчанию в каталоге C:\ProgramData\MySQL\MySQL Server 5.5\data (путь зависит от установленной версии MySQL).
При удалении таблиц, удалении устаревших записей в таблицах место на жестком диске в реальности не освобождается. Оно помечается как неиспользованное внутри этого файла, и потом заполняется вновь записанными данными.
Такая конфигурация в итоге приводит к тому, что этот файл начинает занимать существенный объем жесткого диска - сотни гигабайт и выше. И размер этого файла не уменьшить очисткой старых данных в БД.
При контроле свободного места на ЖД необходимо обращать внимание на этот файл. И если он слишком разрастается - необходимо менять конфигурацию БД.
Для этого потребуется:
<span style="font-weight: 400;">innodb_file_per_table=1</span>
Операции создания и особенно развертывания резервной копии займут значительное время. Если такой длительный простой недопустим, то есть возможность просто перенести файл ibdata1 на другой, более объемный, ЖД.
Для этого нужно:
<span class="token constant">innodb_data_home_dir</span> <span class="token attr-value"><span class="token punctuation">=</span> /path/to/myibdata/</span>указав в качестве параметра новый путь к директории, куда был перемещен файл;