Построение бессерверных филиалов (часть 1)

 Цель — консолидация

Рассмотрим организацию, обладающую сетью удаленных подразделений, которые раскинулись по территории нашей необъятной страны. Пусть есть центральная площадка и N удаленных площадок (здесь N=5 или N=105 – не принципиально).

Зачем этой организации консолидировать все ресурсы на центральной площадке и формировать бессерверные подразделения? Что может не устраивать в существующей схеме? С другой стороны, какие опасности таит консолидация, какие новые проблемы она создаст взамен или в дополнение к прежним?
Если вкратце, то выигрыш в персонале и инфраструктуре.
Инфраструктура удаленного подразделения упрощается. Соответственно снижаются требования к обслуживающему персоналу на местах. Кроме того, в ЦОД уже реализован джентльменский набор сервисов (виртуализация вычислительных систем, виртуализация систем хранения, сервисы информационной безопасности, сервисы для обеспечения непрерывности функционирования и балансировки нагрузки). И управление одной точкой (ЦОД) с меньшим числом компонентов представляется мне более предпочтительным. Опять же, персонал с необходимой квалификацией – уже здесь, в центре.

          Какие проблемы могут встретиться 

У этой медали есть оборотная сторона. Сеть, связывающая подразделение с центральной площадкой, становится критичным местом. Если раньше подразделение обладало относительной автономностью, то после консолидации всех ресурсов в центре становится полностью зависимым от работоспособности центральной площадки и каналов связи с ней. Чаще всего такая WAN-сеть, во-первых, обладает существенно меньшей пропускной способностью по сравнению с LAN, во-вторых, включает в состав неконтролируемые участки и сторонние устройства (например, оборудование и каналы связи оператора, предоставляющего транспорт).
Возьмем для примера электронную почту. В распределенной схеме каждое подразделение имеет локальный почтовый сервер, и почта между сотрудниками подразделения обрабатывается «на месте». Пусть мы убираем почтовые серверы из подразделений и вместо них используем почтовый сервер в центре. Понятно, что в таком случае переписка между сотрудниками «бегает» через WAN-каналы в центр и обратно. Также если одно сообщение адресовано нескольким сотрудникам подразделения, то каждый из них загрузит это письмо через WAN-канал независимо от остальных – получаем избыточное дублирование трафика в WAN.
На этом шаге может возникнуть закономерный вопрос: какие приложения и сетевые службы нужно консолидировать в центре, а какие оставить в подразделении? В локальной сети такой вопрос не стоит: уже канули в лету времена, когда каждая рабочая группа оснащалась своим комплектом серверов. Сейчас для вычислительных систем – ЦОД, для пользователей и их рабочих станций – модуль здания. Если бы WAN-сеть демонстрировала поведение на уровне характеристик LAN, то подразделения можно было бы рассматривать просто как территориально вынесенный модуль здания (с определенными оговорками, конечно, например, в части обеспечения конфиденциальности данных, передаваемых через сеть оператора).
Для удаленных подразделений (и тем более бессерверных) задача-максимум – добиться того, чтобы с точки зрения пользователя работа через WAN была неотличима от работы через LAN.

Как это возможно? Добиться доступности центральной площадки – не проблема: подключаемся к 2 операторам, чтобы зарезервировать WAN-каналы, и запускаем динамическую маршрутизацию в IPsec-туннелях между подразделением и центром.
Но что делать с пропускной способностью, ведь скорость WAN-каналов обычно составляет проценты от скорости каналов локальной сети? Нужно для начала отказаться от предубеждения, что «всё дело в bandwidth», мол, недостаточно пропускной способности канала (и нужно докупить ещё). Конечно, рациональное зерно здесь присутствует, но:
—  во-первых, любой современный компьютер способен запросто загрузить даже гигабитный канал («сколько волка ни корми…»);
—  во-вторых, дело не столько в полосе, сколько в наличии точек с различной скоростью (congestion point), где имеет место конкуренция за ресурс.
Следует, как минимум, в таких точках распознавать и приоритетным образом обрабатывать трафик важных чувствительных (интерактивных) приложений, таких как терминальные клиенты RDP/Citrix, ВКС, телефония, процессы аутентификации и авторизации. Тогда как фоновым приложениям (электронная почта, файловый обмен, печать) можно выделять меньше ресурсов, ведь для них несущественна задержка в 10-30 секунд или даже несколько минут.

          На практике

Организация доступа удаленных подразделений через WAN зачастую следует принципу «главное – чтобы работало», и вопросам гарантий уровня обслуживания и непрерывности функционирования не уделяется достаточно внимания:
—  время отклика при работе зачастую превышает комфортный порог;
—  отказ WAN приводит к недоступности приложений и требует ручного вмешательства для исправления ситуации.
Такая ситуация может даже приниматься как данность. Действительно: приложения получают меньше пропускной способности (в сравнении с LAN), имеет место взаимное влияние сессий и трафика различных приложений. И в случае перегрузок и сбоев сложно оперативно выяснить «кто виноват» – оператор, оборудование КСПД, сервер, клиентская часть или другой компонент инфраструктуры.
В последующих статьях мы исследуем эти вопросы и рассмотрим различные технические решения для достижения необходимого уровня обслуживания и обеспечения непрерывности функционирования удаленных подразделений.