Что происходит, когда сервера, входящие в кластер серверов 1С, расположены в разных подсетях.

Анализ производительности реально работающих информационных систем зачастую преподносит сюрпризы в виде экзотических способов их технической реализации. Данная статья посвящена одному из таких способов, оказывающих влияние на производительность комплекса в целом: размещению серверов, входящих в кластер 1С:Предприятия 8, в разных подсетях.

В ходе выполнения работ по технологическому анализу производительности на территории одного из заказчиков эксперты нашей компании столкнулись с жалобами администраторов 1С на «эпизодически плохую работу сетевого оборудования». Обычно работы, связанные с сетью, не входят в сферу деятельности экспертов по технологическим вопросам, хотя в нашей компании этим занимаются, и даже есть отдельное подразделение (http://specialist-it.ru/). Но у крупных заказчиков для этих целей есть свои службы, которые, как правило, не допускают посторонних к своему оборудованию, в чем совершенно правы. В распоряжении наших экспертов в таких условиях были только штатные средства Windows: ping, tracert, perfmon и свойства подключения в system tray.

Однако в той ситуации хватило и имеющихся средств. С помощью команды tracert было выяснено, что сервера, входящие в кластер 1С:Предприятия 8, не просто находятся в разных подсетях: между ними несколько хопов (прохождений пакета данных через маршрутизаторы). Причем речь не шла о том, что это VLAN-домены для упрощения администрирования – маршрутизация осуществлялась через «физические» роутеры.

При этом ни команда ping, ни команда tracert, ни прочие имеющиеся штатные средства диагностики не давали сведений об имеющихся проблемах. Кроме случаев, когда на сетевом оборудовании действительно проводились профилактические работы, время прохождения пакетов между серверами кластера, а также к серверам СУБД, относительно которых часть серверов 1С также находилась в другой подсети, не превышало 1 мс.

Теи не менее, подобный вариант технической реализации показался нашим экспертам подозрительным, и они обратились за консультацией к соответствующей службе нашей компании (http://specialist-it.ru/), а также инициировали обсуждение в закрытой партнерской конференции 1С (http://partners.v8.1c.ru/forum/thread.jsp?id=857296 - требуется регистрация).

И наши специалисты, и Вячеслав Гилев (www.gilev.ru) дали ответ, что в рассматриваемом случае схема содержит принципиальный изъян. Дело в том, что при прохождении пакета из одной подсети в другую через роутер на нем обязательно происходит задержка пакета на его обработку. Чаще всего и в основном потери времени идут на логирование, но могут быть задержки и на других программных надстройках роутера. Длинные пакеты задерживаются на большее время, чем короткие. В результате штатными средствами (ping и tracert) это задержка не определяется, т.к. там очень короткие пакеты, которые, если нет проблем, проходят быстро. А длинные (работа с СУБД и обмен между серверами) – задерживаются, и это – нормальная работа. Эти задержки на обработку пакетов замедляют работу системы в целом. Их можно минимизировать, но совсем от них избавиться нельзя, и такая работа требует наличия специфичных знаний у специалистов по сетевому оборудованию. Обычная практика в таких случаях – исключать маршрутизацию.

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

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

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