Рекомендации по развертыванию сервера

Данный документ не является полной инструкцией к действию. Он предназначен для общего понимания задачи развертывания сервера FM3 и организации сервиса под требуемые уровни надежности и масштабируемости.

Документ дает общее описание задач, конкретное выполнение которых должно производиться администраторами сервера.

Администратор должен хотя бы поверхностно быть знаком со следующим:

• Администрирование ОС Windows Server – установка компонентов, настройка прав пользователей, настройка файрволла, мониторинг состояния
• Администрирование компонента IIS - управление сайтом, настройка пулов
• Администрирование СУБД MySQL – установка, минимальная настройка и оптимизация параметров, управление пользователями, просмотр статистики использования, создание и развертывание резервных копий
• Работа с ОС Linux – опционально, при условии использования БД на этой ОС.
• Администрирование роутеров/маршрутизаторов – опционально, при наличии их в сети и необходимости проброса портов внутри сети

Развертывание серверов для FortMonitor 3

Всего можно выделить 4 основные части:

• Сервер БД
• Сервер IIS и основных служб FM3 – приемщик данных, обработчик событий и т.д.
• Сервер БД – резервный (опционально, необходимость обуславливается требуемыми показателями надежности системы)
• Сервер адресов (опциональная часть, возможно использование сервиса, который предоставляет Форт-Телеком). В дальнейшем эта часть упоминаться не будет. Инструкция по его развертыванию доступна здесь: http://nominatim.org/release-docs/latest/admin/Ins...

Для каждого сервера необходимо настроить синхронизацию времени.

Для серверов на ОС Windows рекомендуется настроить синхронизацию на обоих серверах с более частым интервалом, например – раз в 30 минут (по умолчанию синхронизация происходит раз в день). Как это сделать можно прочитать, например здесь.

Для серверов с ОС Linux рекомендуется установить NTPD.

Основные части могут быть развернуты как на одном сервере, так и на нескольких – в различных комбинациях:

1. Наиболее простой вариант – все части разместить на одном физическом сервере.
   Плюсом данного варианта является дешевизна в содержании и обслуживании сервера.
   Минусом – крайне низкая надежность: при любой аппаратной проблеме восстановление работоспособности займет достаточно длительное время.
2. Несколько более надежный вариант – развернуть БД на одном сервере (желательно с ОС Linux), а сервер IIS и основных служб - на другом сервере.
   В этом случае общая стабильность системы повысится, т.к. БД очень сильно нагружает дисковую подсистему – а это в свою очередь влияет на время отклика IIS, который также довольно интенсивно использует дисковую подсистему.
3. Следующая ступень для повышения надежности – на отдельном сервере разворачивается резервная БД, которая синхронизируется с основной посредством встроенного в БД механизма репликации. С данного сервера также будет происходить формирование файла резервной копии БД - это позволит снять нагрузку с основного сервера БД.
4. Более сложный вариант – отделение основных служб от IIS. Это может потребоваться, например, при очень большом количестве терминалов или пользователей.

• Если терминалов более нескольких десятков тысяч, то для приема от них данных требуется выделение большого количества сокетов. А это может повлиять на работу IIS и остальных служб, которым также требуется выделение сокетов. В итоге сокетов может просто не хватить, т.к. их максимальное количество ограничено – 65535. Поэтому необходимо приемщик данных вынести на отдельный сервер или развернуть несколько приемщиков данных на разных серверах.
• Если в системе очень большое количество пользователей (более тысячи), то IIS будет занимать большой процент мощности CPU, что негативно скажется на работе сервисов FM3 и увеличит время отклика веб-интерфейса. В этом случае рекомендуется вынести IIS на отдельный сервер, а при количестве клиентов более нескольких тысяч (или при слабом CPU) организовать веб-ферму на нескольких серверах.

В итоге полная структура сервиса может быть такой:

Репликация средствами БД настраивается отдельно. Для MySQL документации довольно много, поэтому ее настройка не должна вызвать серьезных затруднений.

Например, описание создания репликации без остановки основного сервера БД:

https://dba.stackexchange.com/questions/35977/mysq...

Снятие резервных копий может производиться каждый день с помощью планировщика задач или cron – в зависимости от ОС, на которой работает сервер БД.

При снятии копии с основного сервера часто возникает проблема, что копия не консистентна - н-р, при создании датчика во время снятия резервной копии процесс будет прерван, т.к. структура таблиц изменится.

Снятие копии с резервного сервера позволит избежать этой проблемы. Для этого потребуется остановить репликацию, снять копию и снова запустить репликацию.

Такой алгоритм позволит получить 100% консистентный файл резервной копии и снизить нагрузку на основной сервер.

Еще более сложной структурой может быть организация не одного экземпляра резервной БД, а нескольких. К примеру, можно организовать 3х-уровневую структуру:

Основной сервер > Горячий резерв > Холодный резерв.

• Основной сервер – с ним будет работать FM3
• Горячий резерв – будет служить для быстрой замены основного сервера
• Холодный резерв – с него будут сниматься резервные копии

Такая структура позволит при каких-то проблемах с основным сервером быстро переключиться на горячий резерв – при этом холодный резерв станет горячим. И при устранении проблем с бывшим основным сервером сделать из него холодный резерв.

Таким образом получим систему, позволяющую в самом плохом случае пережить отказ основного сервера и горячего резерва, оставшись работать на холодном резерве.

Также для обеспечения надежности приема данных возможно развертывание нескольких копий приемщиков данных. Один из них будет основным, другие – будут находиться в горячем резерве. Либо все они будут принимать данные от какой-то части терминалов.

За распределение нагрузки будет отвечать специальный программный или аппаратный комплекс маршрутизации и балансировки трафика на уровне L4. Он будет следить за доступностью приемщиков данных и направлять трафик к ним.

Конфигурация серверов

При развертывании любого сервера его жесткие диски необходимо организовать в RAID 1 (Зеркало) или более высокий. Это позволит увеличить быстродействие дисковой подсистемы и при выходе из строя одного из дисков заменить его без простоя сервера.

Выбор конфигурации в большой степени зависит от предполагаемой нагрузки на СМТ:

• Если количество данных среднее и пользователей до 100-200 – вполне можно обойтись одним сервером с достаточно производительными и емкими дисками и производительным CPU.
• Если планируется большое количество объектов, по ним будет приходить большое количество данных по многим датчикам, и при этом срок хранения данных большой – необходимо БД выносить на отдельный сервер с емкими и производительными дисками и большим объемом оперативной памяти.
• Если планируется интенсивная работа пользователей, то на отдельный сервер нужно вынести IIS с производительными CPU с большим количеством ядер.

Приблизительная методика расчета требуемого места для БД.

Предположим, что объект присылает данные в среднем 4 раза в минуту.

Помимо навигационной информации передается 4 аналоговых и 10 дискретных датчиков, и на основе аналогового датчика создан датчик топлива. Итого 1 пакет будет занимать:

100 + 4*8 + 10*1 + 1*8 = 150 байт.

На самом деле объем будет больше – т.к. информация на диске всегда фрагментирована, и плюс к этому необходимо место для хранения индексов в БД. Индексы в БД служат для ускорения поиска нужных данных и могут занимать место, сравнимое с объемом самих данных.

Учитывая эти нюансы, на хранение информации за 1 год по 1 объекту потребуется минимум 500 МБайт дискового пространства.

С учетом того, что идет постоянный рост количества передаваемой информации от терминалов (CAN-шина, дополнительное навесное оборудование и т.д.), то можно планировать 1-1.5 ГБайт на 1 объект за 1 год.

Внимание! Это размер только БД! Если конфигурация такова, что весь сервис располагается на одном сервере, необходимо учитывать место под остальные сервисы, в частности – данные, принятые от терминалов, различные логи – в том числе и системные.

Если в конфигурации серверов присутствует резервный сервер БД, то необходимо предусмотреть место для ведения бинарных логов. В идеале это должен быть отдельный жесткий диск для уменьшения нагрузки на основную дисковую подсистему.

Если БД и сервисы размещены на разных серверах, необходимо настраивать синхронизацию времени на этих серверах. Расхождение во времени в несколько секунд может привести к тому, что последнее местоположение объектов на карте может отображаться совсем не там, где на самом деле находятся эти объекты.

Причем для ОС Windows встроенная синхронизация не всегда работает корректно. Требуется изменение интервала синхронизации времени – уменьшение его до получаса или часа.

Оперативная память достаточно критична для работы БД. Идеальным считается вариант, когда вся БД помещается в оперативную память. В этом случае практически полностью снимается нагрузка на жесткие диски (за исключением нагрузки на запись) и уменьшается время отклика системы в целом.

Как правило, такого идеального варианта достигнуть не получается. Поэтому желательно, чтобы в память помещались хотя бы индексы БД – это обеспечит более быстрый поиск нужной информации и снизит чтение информации с диска.

Мониторинг серверов

Какой бы ни была конфигурация серверов, на каждом из них необходимо настраивать мониторинг основных параметров.

Для всех типов серверов всегда нужно контролировать следующие параметры:

• Загрузка CPU
• Свободная оперативная память
• Свободное дисковое пространство
• Нагрузка на жесткие диски
• S.M.A.R.T. – состояние жестких дисков. Контроль Reallocated Sectors, температуры и других параметров, показывающих состояние диска, по которым можно определить, что с диском начинаются проблемы и его необходимо заменить.
• Нагрузка на сеть

Для сервера БД дополнительно можно контролировать состояние MySQL – количество запросов в секунду (select, insert, update), количество соединений к БД и т.д.

Для сервера IIS контролировать параметры IIS – количество запросов в секунду, количество установленных соединений, количество запросов в очереди, среднее время выполнения запроса и т.д.

Для особо критичных параметров необходимо настроить уведомления, по которым срочно нужно принимать меры.

К таким параметрам можно отнести:

• Свободное дисковое пространство – если на сервере БД не будет свободного места, БД просто перестанет работать, при этом весьма вероятна потеря части данных.
• Свободная оперативная память – если на сервере с IIS памяти останется менее 5%, то он не будет принимать никакие запросы.
• S.M.A.R.T. – если диск начинает “сыпаться”, это критично скажется на работе БД и может привести к повреждению БД вплоть до ее полной утери.
• CPU – если на сервере IIS процессор загружен более чем на 90%, то отключается механизм сжатия выдаваемой информации. Это приводит к общему замедлению выдачи результатов запросов и излишней нагрузке на сеть.
  Если это сервер БД или сервер с сервисами ФМ3 – то все операции занимают большее время, падает общая эффективность и производительность системы.

Мониторинг данных параметров можно настроить с помощью любой системы мониторинга серверов – 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"

Файлы, которые необходимо контролировать вручную

1. Принятые данные от терминалов записываются в каталог \ML3\Source\. Они служат для возможного восстановления данных или для выяснения, почему какие-то данные не попали в БД.
   Запись этих данных можно отключить, записав в таблицу f_server_properties ключ `ml3_to_sources` со значением `False`. После этого нужно перезапустить fmKeeperService.
   Эти данные очищаются автоматически, если задан срок хранения данных. Если данный срок не задан (значение 0), то они очищаться не будут. При этом они достаточно объемные, и рано или поздно займут все свободное место на диске, поэтому периодически их необходимо очищать вручную.
   Есть возможность включить автоматическое архивирование файлов за прошлый месяц. Для этого необходимо записать в таблицу f_server_properties ключ `helper_archive_sources` со значением `True`. После этого нужно перезапустить fmKeeperService.
   Архивирование производится 1го числа в 00:10 по серверному времени. Архивируются файлы за прошлый месяц в архив 7z, после проверки архива на корректность файлы удаляются.
2. Если на сервере стоит настройка “Сохранять данные перед удалением” – данные будут сохраняться в каталог \fmCleaner\obj_data\. Автоматически эти данные не очищаются, поэтому необходимо вручную контролировать их объем и своевременно очищать.
3. Различные логи. Если срок хранения задан =0 (т.е. вечно), то необходимо контролировать следующие каталоги:
   \ML3\Photos – фотографии, принятые от терминалов.
   \ML3\Blocked – принятые данные от терминалов, которые были заблокированы. Хранятся на случай, если терминал был ошибочно заблокирован и по нему нужно восстановить данные. Запись этих данных можно отключить, записав в таблицу f_server_properties ключ `ml3_to_sources_blocked` со значением `False`. После этого нужно перезапустить fmKeeperService.

Контроль таблиц в БД

1. Основной объем БД составляют таблицы с данными от оборудования. Часто бывает так, что терминалы начинают “спамить” – т.е. присылать излишнее количество данных. Такие терминалы можно выявить, запросив отчет “По работе системы” за текущие сутки (находится в группе отчетов “Сервисные отчеты”). В конце этого отчета будет приведен список терминалов, посылающих за сутки более 20 000 пакетов. Подобные терминалы рекомендуется перенастраивать – например, уменьшать частоту посылки данных на стоянке, убирать генерацию внеочередных пакетов при активации входов, которые не нужны и тому подобное.
2. Если в настройках задан срок хранения данных =0, то данные от терминалов в БД будут храниться вечно. При этом также вечно будут храниться данные в различных сервисных таблицах – в основном это различные логи.
   Существуют настройки, которыми можно отключить ведение различных логов:

• Лог подключений/отключений терминалов (f_logs_terminals). По умолчанию он ведется, и по нему можно понять, когда именно терминал подключался к системе и в каком протоколе передавал данные, сколько пакетов было передано и сколько длилось подключение. Данный лог в 90% случаев не требуется, и его можно отключить, записав в таблицу f_server_properties ключ `ml3_log_terminal_actions` со значением `False`. После этого нужно перезапустить fmKeeperService.
• Логи системы (f_logs) – отключить их нельзя, но можно задать срок хранения. Для этого в таблицу f_server_properties нужно записать ключ `cleaner_logs_month` со значением, равным количеству месяцев. После этого нужно перезапустить fmKeeperService.
  Внимание! К этим логам относятся логи действий пользователей, они также будут очищаться.

Конфигурация БД

В версиях MySQL ранее 5.6 в конфигурации параметр innodb_file_per_table выставлен в значение 0.

Это значит, что все базы и все таблицы в них хранятся в одном огромном файле ibdata1, который находится по умолчанию в каталоге C:\ProgramData\MySQL\MySQL Server 5.5\data (путь зависит от установленной версии MySQL).

При удалении таблиц, удалении устаревших записей в таблицах место на жестком диске в реальности не освобождается. Оно помечается как неиспользованное внутри этого файла, и потом заполняется вновь записанными данными.

Такая конфигурация в итоге приводит к тому, что этот файл начинает занимать существенный объем жесткого диска - сотни гигабайт и выше. И размер этого файла не уменьшить очисткой старых данных в БД.

При контроле свободного места на ЖД необходимо обращать внимание на этот файл. И если он слишком разрастается - необходимо менять конфигурацию БД.

Для этого потребуется:

1. Остановить полностью всю работу FM3;
2. Создать резервную копию;
3. Переустановить MySQL;
4. Задать параметр

   <span style="font-weight: 400;">innodb_file_per_table=1</span>

5. Развернуть резервную копию
6. Запустить сервисы FM3;

Операции создания и особенно развертывания резервной копии займут значительное время. Если такой длительный простой недопустим, то есть возможность просто перенести файл ibdata1 на другой, более объемный, ЖД.

Для этого нужно:

1. Остановить полностью всю работу FM3;
2. Остановить БД;
3. Перенести файл на новый ЖД;
4. В файле конфигурации БД задать параметр

   <span class="token constant">innodb_data_home_dir</span> <span class="token attr-value"><span class="token punctuation">=</span> /path/to/myibdata/</span>

   указав в качестве параметра новый путь к директории, куда был перемещен файл;
5. Запустить MySQL;
6. Запустить сервисы FM3;