Рассмотрим типичную ситуацию: компания N помимо центрального офиса открыла несколько филиалов в разных городах и продолжает расти. На совете директоров руководитель ИТ-службы периодически докладывает о необходимости построить единую распределенную корпоративную сеть. Он добавляет, что использовать Internet для обмена информацией между штаб-квартирой и удаленными площадками уже не модно, а модно — строить виртуальные частные сети.
Конечно, у «айтишников» всегда найдется куча идей по поводу того, как потратить деньги своей компании. Однако на сей раз они обещают довольно быстрый возврат инвестиций, а в дальнейшем — повышение прибыльности бизнеса за счет улучшения общей эффективности работы структурных подразделений. Все это звучит заманчиво, поэтому совет директоров принимает решение построить распределенную корпоративную сеть. Специально обученные сотрудники начинают «рисовать» проект, составлять спецификации на активное оборудование, серверы и программное обеспечение.
И, вроде бы, пора уже приступать к реализации намеченного, но возникают вопросы о способах организации и типах каналов, которые будут связывать головной офис с филиалами. Нужно определить для каждого канала ширину полосы пропускания, используемые технологии, физические интерфейсы окончаний на стороне пользователя и прочие параметры. Такие вопросы, как правило, задают интеграторы, привлеченные к реализации проекта. А ответа от заказчика они обычно не получают, поскольку тот озабочен совсем другими проблемами. Тогда интегратор советует клиенту выбрать оператора связи и обратиться к нему. Но его правильный выбор и верная формулировка запроса — тема отдельного разговора.
Предположим, заказчик при помощи поисковых систем в Internet нашел операторов, удовлетворяющих его требованиям, и обратился к наиболее понравившемуся с просьбой предоставить в аренду каналы связи. Вместо ответа он опять слышит повторение вопросов о том, какие каналы ему нужны. Оператор высылает опросники, изобилующие непонятными терминами, а затем подолгу не реагирует на уточняющие письма. В общем, процесс построения сети затягивается.
Наконец, в отношении требуемых каналов связи появляется определенность. ИТ-директор несет предложение оператора на утверждение гендиректору, но тот, удивленный значащимися в смете цифрами, требует каких-либо гарантий: если уж платить такие деньги, то за качественную услугу. Перед ИТ-отделом встает новая задача: заключить с оператором договор об уровне сервиса (Service Level Agreement, SLA). И все начинается сначала. Какие требования к каналам выдвинуть? Как изложить их оператору так, чтобы он их понял? Как составить договор, чтобы в случае невыполнения оператором его обязательств компания могла предъявить претензии?
Конечно, на все вопросы необходимо найти ответы еще до подписания договора об аренде каналов связи. Есть несколько способов справиться с этой задачей, но самым эффективным является привлечение специалистов, владеющих «русско-клиентским» и «русско-операторским» языками одновременно. Они способны выяснить у заказчика, чего же он, собственно, ожидает от услуг, а потом «транслировать» его тезисы оператору. Для поиска таких людей заказчику следует обратиться в интеграторскую фирму, предлагающую услугу «Организационно-технические мероприятия по организации каналов связи». Со стороны интегратора к работе будут привлечены квалифицированные инженеры-проектировщики и менеджеры с большим опытом общения с операторами связи.
После фиксации в договоре требований к качеству услуг надо удостовериться, что выбранное сетевое оборудование поддерживает возможность задания настроек в области классификации и приоритизации трафика, иначе в проблемах с качеством сервиса будет виноват сам заказчик. Не исключено, что ради получения такой функциональности придется пересмотреть качественный состав сетевого оборудования и даже первоначальный список производителей. Таким образом, к проектированию сетевой части решения лучше подходить уже после выбора поставщика услуг и подписания SLA.
Дальше — больше. Оказывается, недостаточно подобрать оборудование, имеющее гибкий инструментарий управления QoS. Необходимо настроить его в соответствии с утвержденными параметрами SLA. Задача эта — отнюдь не тривиальная, и поручать ее лучше квалифицированным специалистам. В договор с системным интегратором неплохо отдельной строкой внести пункт о таких услугах.
Наконец, все препятствия позади. Распределенная корпоративная сеть запущена в эксплуатацию, и даже довольно быстро окупается. Она превратилась в привычный инструмент ведения бизнеса, ведь пользователи довольно быстро привыкают к хорошему. Но только ИТ-директор начинает вынашивать новые планы внедрения информационных технологий в бизнес-структуру, глава компании вызывает его к себе и требует отчета о соблюдении оператором условий SLA. На повестку дня выходит вопрос срочного внедрения средств мониторинга, способных отслеживать соответствие заявленного качества обслуживания фактическому. Для выбора подходящего решения и его настройки лучше обратиться к тем, кто занимаются такими задачами на постоянной основе.
Следует понять, выполнением каких именно пунктов SLA нужно озаботиться в первую очередь. Чаще всего заказчик обращает внимание на банальную доступность удаленной площадки в терминах «связь есть» и «связи нет». Но порой необходимо отслеживать значения таких параметров, как задержки прохождения пакетов, их вариации (jitter), время установления TCP-соединения и исполнения запроса к серверу DNS.
Для проверки доступности удаленного узла применяют множество решений, начиная с самодельных скриптов (которые с заданной периодичностью определяют, откликается ли удаленная площадка на запросы по ICMP) и заканчивая профессиональными системами, такими как HP OpenView NNM. Вместе с тем измерение величины задержек и прочих параметров качества требует использования встроенных функций активного сетевого оборудования или сложных дорогих программных комплексов операторского класса. Если для создания корпоративной VPN-сети используются маршрутизаторы Cisco Systems, задача существенно упрощается: мониторинг сети в режиме реального времени можно осуществлять с помощью встроенной функциональности Cisco IOS IP SLA. При несоответствии фактического уровня сервиса ожидаемому устройство с поддержкой IOS IP SLA отсылает уведомления системам управления или даже перенаправляет трафик на другие внешние каналы.
Последний вопрос, возникающий у компании в связи с переходом на распределенную сеть VPN: что делать, если оператор не выполняет условия соглашения, то есть системы мониторинга QoS показывают, что прописанные параметры не обеспечиваются? Естественно, вооружившись журналами событий и отчетами, обратиться к оператору для урегулирования спора. Если же этот вариант не проходит, следует в очередной раз обратиться к специалистам, на сей раз — в сфере юриспруденции.
Денис Дыжин (dyzhin@jet.msk.su) — PMP, CCIE, менеджер отдела инженерной поддержки продаж компании «Инфосистемы Джет»