ЛИНТЕР

Выбор временных интервалов

В большинстве случаев требуется быстрая реакция системы резервирования на отказ одного из серверов. Для этого при запуске сервера резервирования необходимо установить в минимальное значение интервал посылки тестовых пакетов и максимальное количество пропущенных тестовых пакетов.

Время реакции системы резервирования на нештатную ситуацию равно произведению интервала тестовой посылки (ключ /testint) и максимального количества пропущенных пакетов (ключ /tstlimit). Необходимо учитывать, что при посылке UDP-пакетов один или даже несколько подряд посланных пакетов могут потеряться (сеть не гарантирует доставку), поэтому устанавливать количество пропущенных пакетов меньше 3 – 4 не рекомендуется. В такой ситуации время реакции лучше регулировать уменьшением интервала посылки.

Интервал посылки может быть задан в командной строке не только целым числом, но и вещественным (т.е. реально можно задать интервал посылки в одну десятую сек.). Минимальный интервал необходимо подбирать опытным путем на реальной сети при реальной нагрузке на неё.

Для этого:

запустить на выполнение какие-либо задачи, эмулирующие максимальную нагрузку сети. Количество задач должно быть достаточным для тестирования устойчивости системы резервирования при повышенных нагрузках на сеть;
создать БД такого размера, чтобы её первоначальное копирование с главного компьютера на резервный компьютер без нагрузки на сеть было порядка нескольких минут;
запустить систему резервирования с выбранным для эксперимента (эмпирическим путем) интервалом посылки и количеством пакетов. Если соединение между серверами устойчиво и первоначальное копирование БД прошло успешно с первой попытки, то такое время реакции системы резервирования приемлемо в данной конфигурации сети;
уменьшить время реакции системы резервирования, например, в 2 раза, и повторить проверку её работы. Если хотя бы один из резервных серверов перешел за время проверки из SLAVE-состояния в SLAVE_WAIT-состояние (повторил первоначальное копирование БД) или вообще завершил работу, значит, выбранное время реакции является ошибочным. Его необходимо увеличить в несколько раз и повторить попытку. Таким образом, экспериментальным путем подбирается минимальное время реакции системы резервирования для конкретной сети. Для надежности найденное значение можно увеличить в 2 раза.

Время реакции системы резервирования необходимо учитывать при подготовке файла nodetab. В нем значения всех тайм-аутов должны быть больше времени реакции системы резервирования. Необходимо также учитывать, что минимальные тайм-ауты в файле nodetab должны быть не менее 4 сек., иначе работа сетевых драйверов СУБД ЛИНТЕР может стать нестабильной.

Тайм-аут проверки ядра СУБД ЛИНТЕР (примечание к ключу /treq) должен выбираться, исходя из особенностей пользовательского приложения и остальных настроек сервера резервирования:

не рекомендуется выбирать тайм-аут меньше, чем учетверенный интервал посылки тестовых сообщений, поскольку все временные операции сервера резервирования тактируются с периодичностью интервала посылки;
интервал посылки тестовых запросов ядру СУБД ЛИНТЕР рекомендуется выбрать равным четвертой части тайм-аута СУБД ЛИНТЕР;
тайм-аут ядра СУБД ЛИНТЕР рекомендуется выбирать немного больше, чем время выполнения самого длительного запроса приложения при максимальной нагрузке на ядро;
при выборе тайм-аута ядра необходимо учитывать возможное накопление данных в процессе работы системы резервирования и, если возможно, проверять длительность выполнения пользовательских запросов на реальных объемах данных и в окружении всех прикладных задач (при увеличении объемов время исполнения запроса также увеличивается). В связи с тем, что минимальный интервал посылки тестового запроса ядру СУБД ЛИНТЕР не может быть установлен меньше 1 сек., тайм-аут ядра СУБД ЛИНТЕР не рекомендуется выбирать менее 3-4 сек.;
тайм-аут ожидания останова ядра СУБД ЛИНТЕР (ключ /forceshut) должен выбираться с таким расчетом, чтобы обеспечивать передачу всех данных на резервный сервер после получения ядром СУБД ЛИНТЕР команды останова.

Для определения этого тайм-аута необходимо:
- запустить систему резервирования с пиковой (максимальной) нагрузкой;
- предоставить главному серверу возможность отработать в период пиковой нагрузки в реальной системе;
- после этого подать главному серверу команду останова. Время, за которое главный сервер завершит свою работу, и будет рекомендуемым тайм-аутом ожидания останова. Для надежности это время необходимо увеличить в полтора-два раза;
интервал ожидания готовности всех серверов резервирования (ключ /wait) должен быть больше, чем разница во времени готовности компьютеров резервирования после включения. Если автоматический запуск системы резервирования запрещен, то этот ключ игнорируется, т.к. момент запуска системы резервирования будет определяться разрешением на запуск (администратором системы резервирования или сигналом). Если разрешен автоматический запуск системы резервирования, то данный тайм-аут должен гарантировать запуск всех компьютеров системы резервирования до его истечения.