Capacity Planning для сети

Александр Гуляев, начальник отдела сетевых проектов компании «Инфосистемы Джет»

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

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

Планирование емкости СПД — процесс, наиболее близкий к «физике», к оборудованию и технологиям передачи данных. Дело в том, что логическая структура сети, как правило, обеспечивает решение функциональных задач, но не всегда является ключевым фактором при определении производительности решения. Хотя следует отметить: чем более сложной и многоуровневой становится сетевая инфраструктура, тем больше нужно обращать внимание на наличие логических уровней в архитектуре и тем более важную роль они начинают играть в вопросах оптимизации¹.

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

• планирование характеристик сети при ее проектировании;
• планирование развития ЛВС или сети ЦОД;
• планирование создания и развития сети оператора.

Разберем эти варианты более подробно.

Что нам стоит сеть построить

При создании новой сети типичными задачами для проектировщика являются определение требований к ней (текущих и перспективных) и выбор наиболее оптимального решения по оборудованию². Какой-либо четкой, единой методики, как это правильно сделать, не существует, обычно используются рекомендации вендоров и известные характеристики оборудования: производительность, поддерживаемые интерфейсы, наличие переподписки³, функциональная совместимость.

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

• что именно и как будет присоединяться к сети;
• количественную оценку потоков данных от смежных систем (например, вычислительного комплекса);
• направления этих потоков;
• режим работы смежных систем (в какой момент времени можно ожидать пик нагрузки);
• требования по допустимой задержке передачи данных и критичность минимизации этой задержки;
• требования к допустимости потери трафика в сети из-за переподписки и возможных перегрузок.

Первые три пункта наиболее важны, но и остальными нельзя пренебрегать, особенно в ситуации, когда в сети будут работать приложения, требующие минимизации времени передачи данных (системы реального времени, приложения для online trading), либо протоколы сети хранения данных, не допускающие потери трафика (например, FCoE). В любом случае все требования могут оказать влияние на топологию, выбор оборудования и физическую структуру сети.

Например, для ЦОД с большим объемом трафика систем виртуализации в направлении East-West производители оборудования уже который год рекомендуют строить «плоские» L2-сети с сокращением количества уровней архитектуры ЛВС (предлагается отказ от уровня распределения).

Для критичного же к задержке трафика online trading можно рекомендовать топологию full mesh с использованием оборудования, поддерживающего идеологию Ethernet Fabric (TRILL, FabricPath) и функционал L2 ECMP. Если при этом потоки трафика не только критичны к задержке, но и велики, целесообразнее применять оборудование, имеющее интерфейсы 40G или 100G Ethernet.

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

Отметим, что вопрос формирования требований к сети может вызвать определенную сложность: далеко не для всех приложений заранее известны объемы создаваемого трафика. Тем более сложно оценить, как трафик различных систем будет в совокупности загружать сеть. Наиболее правильным решением будет получение значимого объема статистики загрузки основных направлений различными приложениями с помощью сетевых анализаторов или системы управления.

Планирование емкости сети особенно актуально в настоящее время, когда в связи с всеобщей виртуализацией повышаются требования к производительности сети и минимизации задержек⁵. Важно чтобы все стороны процесса — и заказчик, и исполнитель — понимали важность этой задачи, и выбираемые решения были обусловлены техническими показателями, а не внешними факторами (отсутствие или стоимость каналов, бюджеты на оборудование и т.д.). Бюджет может быть большим или маленьким, главное, чтобы он был обоснованным.

Модернизация ЛВС и сетей ЦОД

Планирование развития ЛВС или сети ЦОД является существенно более комплексной задачей, особенно в ситуации, когда эта процедура проводится в первый раз. Основная сложность заключается в сборе исходных данных, причем трудоемкость напрямую зависит от наличия в сети средств управления и инвентаризации.

Как правило, его этапы выглядят следующим образом:

• актуализация топологии сети, физических и логических связей;
• инвентаризация оборудования и его задействованных ресурсов (определение типа и количества занятых и свободных портов);
• определение принадлежности портов сетевого оборудования к тем или иным ИТ-системам;
• сбор операционной информации с сетевого оборудования (утилизация процессора и загрузка интерфейсов);
• формирование требований к развитию сети — увеличение ее емкости:
  • по портам подключения (посистемно);
  • по объемам трафика (посистемно);
• анализ данных и выработка основных подходов к расширению сети, их согласование;
• разработка технического решения по расширению сети⁶;
• оценка бюджета модернизации: стоимости оборудования и работ.

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

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

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

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

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

Сети сетей

Планирование развития сетей передачи данных для операторов связи коренным образом отличается от аналогичных процедур для ЦОД и корпоративных сетей. Основные отличия продиктованы особенностями этой задачи в операторском сегменте. Во-первых, сетевая инфраструктура практически всегда масштабна: речь идет о сотнях или даже тысячах устройств и каналов связи в распределенной СПД. Во-вторых, у телекоммуникационных компаний, как правило, есть различная транспортная инфраструктура, имеющая собственную емкость, логическую структуру и связность: волоконно-оптические линии связи, собственный оптический транспорт, арендованные каналы, сегменты SDH/PDH, IP/MPLS-сеть. В-третьих, сеть постоянно меняется: как показывает практика, программы модернизации СПД у операторов связи масштабны и растянуты во времени, поэтому изменения состава устройств и характеристик каналов происходят на различных участках практически ежедневно.

Можно отметить и другие особенности:

• наличие смежных задач, таких как комплексный анализ отказоустойчивости сети (SLRGs⁷, «What-if»⁸);
• тесная взаимосвязь задачи планирования развития СПД с процедурами прогнозирования нагрузки, планирования новых сетевых подключений, т.е. необходимость интеграции с маркетинговыми прогнозами и процессами OSS (Operations Support System), наличия отдельных продуктов для анализа статистики трафика и прогнозирования нагрузки;
• необходимость в автоматизированной разработке различных вариантов бюджетов развития сети (оптимистичный, пессимистичный, сбалансированный) и перечня соответствующих мероприятий для каждого сценария;
• возможность получения существенного экономического эффекта при изменении логической структуры сети и оптимизации маршрутов прохождения трафика (т.е. задействование скрытых ресурсов сети и снижение стоимости модернизации оборудования и каналов связи);
• возможность поэтапного ввода в строй новых сегментов сети, что позволяет растянуть инвестиции во времени, обеспечив при этом требуемые показатели качества работы СПД;
• необходимость постоянного отслеживания изменений топологии сети с актуализацией сетевой модели;
• необходимость просчитывать последствия предстоящих изменений с помощью механизмов оптимизации и моделирования распределения трафика;
• необходимость учитывать наличие в сети оборудования различных вендоров и рассмотрения соответствующих ценовых моделей при планировании бюджета.

Такой набор требований естественным образом расширяет задачу планирования сети до планирования и управления ее емкостью (Capacity Planning & Management), что требует широкой поддержки со стороны различных, уже имеющихся у операторов процедур и процессов (см. Рис. 1).

Рис. 1. Обеспечивающие процессы для Capacity Planning сети оператора

С практической точки зрения задача Capacity Planning & Management требует очень большого объема актуальных входных данных, причем с минимально возможной задержкой между изменениями в сети и их отображением в моделируемой топологии. В противном случае все изменения распределения трафика в реальной сети будут отображаться некорректно. В идеале должно быть налажено двустороннее online-взаимодействие между сетью и инструментами Capacity Planning & Management.

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

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

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

Рис. 2. Пример структурной схемы процесса Capacity Planning

Этапы процесса планирования емкости сети

В рамках статьи мы не будем подробно рассказывать обо всех этапах процесса, предлагаемого на схеме. Остановимся лишь на двух основных моментах, характерных для любого процесса планирования сети: топологии и трафик-матрице.

Топология СПД — комплексная сущность, включающая в себя в общем случае как физическую, так и логическую структуру сети, а также данные из системы инвентаризации оборудования. Топология может рассматриваться с различными уровнями детализации: Net2Net (связность между сетями или автономными системами), POP2POP (связи между узлами сети, в которых физически размещается оборудование), Device2Device (физическая топология сети с отдельными устройствами). При увеличении детализации топологии до уровня Device2Device сложность получающейся схемы драматически возрастает, но, к сожалению, именно этот уровень детализации позволяет эффективно решать задачи бюджетирования. Дело в том, что на уровне POP2POP и выше не учитывается конкретное сетевое оборудование, работающее в СПД. Логическая структура сети — это совокупность настроек протоколов, маршрутов и путей прохождения трафика, поддерживаемых матрицами кросс-коннектов мультиплексоров, протоколами маршрутизации и технологиями типа MPLS. Как правило, системы оптимизации сети умеют обрабатывать входные данные о ее логической организации в том или ином стандартизованном формате либо получают их непосредственно с сетевого оборудования.

Трафик-матрица — это описание потоков трафика в сети. Для правильного расчета ее емкости потоки трафика должны быть также дифференцированы по приложениям и показателям качества сервиса. В противном случае невозможно определить, имеется ли запас емкости канала для критичного трафика, или вместе с трафиком класса best-effort в результате перегрузки начнет отбрасываться критичный трафик голоса или сетевой сигнализации. Для сбора информации и формирования исходной трафик-матрицы на первоначальном этапе часто применяют анализ статистики NetFow. В дальнейшем при прогнозах поведения сети обычно используют процентное увеличения объемов того или иного конкретного вида трафика. Трафик-матрицу также можно попытаться построить исходя из маркетинговых прогнозов продаж минут и мегабайт трафика. Но на практике применение этого способа может быть эффективно только для вариантов анализа сети на уровне Net2Net или POP2POP, в наиболее простых случаях и когда точно определены точки входа и выхода трафика.

Читателю уже должно быть очевидно, что решение задачи Capacity Planning & Management на сети современного крупного оператора связи требует использования специализированных коммерческих инструментов. Хорошая новость состоит в том, что такие системы на рынке есть. Они отличаются друг от друга набором поддерживаемых сетевых технологий, средств оптимизации топологии и логической структуры сети, широтой охвата решаемых технических и экономических задач. Не очень хорошая новость заключается в стоимости как их самих, так и их внедрения: зависимости от объемов сети и предоставляемых сервисов речь может идти о миллионах долларов. В то же время внедрение таких решений в долгосрочной перспективе будет приносить весьма ощутимую прибыль операторам за счет «выравнивания» бизнес-потребностей с возможностями сети. Неспособность СПД пропустить необходимый объем трафика и необоснованно затратная модернизация сети⁹ приводят к одному результату: снижению прибыли оператора. В настоящее время, когда тарифные войны вынуждают операторов искать все новые и новые способы увеличения прибыли, возможность сократить бюджет модернизации за счет выявления скрытых резервов сетевой топологии или расчета наиболее эффективной стратегии модернизации явно не будет лишней.

Игроки на рынке

В числе производителей коммерческого ПО для планирования и управления емкостью операторских сетей следует назвать следующие компании (представленный список далеко не исчерпывающий):

• компания Cariden (США): семейство продуктов Mate;
• Opnet (США);
• WANDL (США);
• Aria Networks (UK).

Решения каждого из этих вендоров внедрены в ряде операторов за рубежом, но на данный момент нам неизвестно о каком-либо полномасштабном внедрении продукта такого класса в России.

Если рассматривать только задачу исследования и оптимизации топологии сети IP/MPLS, можно также упомянуть продукт TOTEM (TOolbox for Traffic Engineering Methods), свободно распространяемый под лицензией GPLv2. Он широко используется институтами и отдельными исследователями в научной среде для моделирования трафика и расчета различных сетевых задач, т.к. содержит ряд алгоритмов, используемых и в коммерческих продуктах: расчеты распределения трафика в сети, стоимости маршрутов для оптимизации загрузки каналов, анализ «What-if» и ряд других. Использование такого инструмента, безусловно, не позволяет полноценно решить все задачи оптимизации сети оператора, но дает возможность понять их специфику и техническую проблематику.

¹ Это особенно актуально для сетей операторов связи, в которых имеется взаимосвязь между различными технологиями уровня сетевого транспорта: xWDM, SDH/PDH, IP, MPLS. Хороший пример попытки связать различные транспортные уровни для обеспечения оптимизации потоков и отказоустойчивости — это технология GMPLS.

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

³ Как правило, этот термин обозначает наличие ограничений в каком-либо компоненте технической системы, лимитирующих показатели ее работы в целом. На практике каждый ресурс стоит денег, поэтому наличие в системе переподписки (в той или иной форме) является признанным средством управления стоимостью решений.

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

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

⁶ Или вариантная разработка, если это возможно.

⁷ SRLG (Shared Risk Link Group) — группа каналов, объединенная общей инфраструктурой, выход из строя которой влечет за собой различные множественные проблемы передачи данных для разных систем. Примером является порыв многоволоконной оптической трассы, в которой волокна использовались для передачи трафика различных систем или разных сегментов сети. Различают node, channel и subnet SRLGs — когда проблему вызывает выход из строя канала, узла или логической взаимосвязи между сетевыми элементами соответственно. Дизайн отказоустойчивой сети должен избегать наличия SRLG, которая делает сеть уязвимой к одиночному выходу из строя какого-либо компонента. SRLG не обязательно приводит к неработоспособности сети, ее наличие может выразиться во временном сбое либо перегрузке каких-либо сегментов СПД.

⁸ «What-if» analysis (анализ «что если») — моделирование перераспределения трафика в сети в случае изменения логической или физической топологии. Широко используется при проектировании новых сегментов сети для анализа вариантов наиболее эффективного изменения топологии.

⁹ Для этого понятия существует даже специальный термин — overprovisioning.

Контактная информация

Наши сайты: www.jet.su, www.jetinfo.ru. Электронная почта: info@jet.su.

Другие статьи раздела «Вся «фишка» — в управлении»