© 1995-2021 Компания «Инфосистемы Джет»
Capacity Planning для сети
Сетевые решения

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

07.12.2012

Посетителей: 220

Просмотров: 174

Время просмотра: 4.4 мин.

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

 

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

Сети сетей 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 


 

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


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


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


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


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


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


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


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

Уведомления об обновлении тем – в вашей почте

Эксплуатация ЦОД. Что лучше: аутсорсинг или своя команда?

Любые сложные инженерные системы, а к таковым, безусловно, относятся системы центров обработки данных (ЦОД), нуждаются в обслуживании

Кто на новенькое

На текущий момент о задаче управления инцидентами ИБ уже сказано очень много, и каждая крупная компания реализовала ее или сделала 1–2 подхода к построению этого процесса

Кому с DCIM жить хорошо

Следующий вопрос, который возникает в свете детального разбора DCIM-решений, – каким компаниям подобные системы могут принести максимальную пользу

Распределенные центры обработки данных

Резервный вычислительный центр (РВЦ) — это одно из решений, направленных на обеспечение доступности данных и информационных служб в целом.

Модульные ЦОДы

Основой для возникновения этого решения в свое время послужили мобильные ЦОДы

Когда стоит задуматься о Quality Assurance

Анализируя ситуацию на рынке ЦОД, мы можем констатировать, что услуга Quality Assurance реально востребована российским бизнесом последние 1–2 года.

Сокращение энергопотребления систем кондиционирования

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

Миграционный вопрос

Как организовать и провести ИТ-миграцию, обеспечить безболезненный переезд ИТ-систем

Курс на объединение и модернизацию ЦОД

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

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня