ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

11 минут чтени€

„етверта€ часть тут

ќписанные до сих пор технологииЧкоммутаци€ каналов и пакетов, плоскости управлени€ и QoSЧочень сложны. Ќа самом деле, по-видимому, нет конца растущей сложности сетей, особенно по мере того, как приложени€ и предпри€ти€ станов€тс€ все более требовательными. ¬ этой лекции будут рассмотрены два конкретных вопроса, св€занных со сложностью и сет€ми:

  • „то такое сложность сети?
  • ћожно ли Ђрешитьї сложность сети?

ѕочему сети должны быть сложными?

’от€ наиболее очевидным началом понимани€ темы может быть определение сложности, но на самом деле более полезно рассмотреть вопрос, почему сложность требуетс€ рассмотреть в более общем смысле. ѕроще говор€, возможно ли Ђрешитьї сложность? ѕочему бы просто не проектировать более простые сети и протоколы? ѕочему кажда€ попытка сделать что-то более простое в сетевом мире в конечном итоге €вно усложн€ет ситуацию в долгосрочной перспективе?

Ќапример, благодар€ туннелированию поверх (или через) IP сложность плоскости управлени€ снижаетс€, а сеть в целом упрощаетс€. ѕочему тогда туннельные оверлеи сложны?

≈сть два ответа на этот вопрос. ¬о-первых, поскольку человеческа€ природа €вл€етс€ тем, чем она €вл€етс€, инженеры всегда будут изобретать дес€ть различных способов решени€ одной и той же проблемы. Ёто особенно верно в виртуальном мире, где новые решени€ (относительно) просты в развертывании, (относительно) легко найти проблему с последним набором предлагаемых решений, и (относительно) легко создать новое решение, которое Ђлучше старогої. Ёто особенно верно с точки зрени€ поставщика, когда создание чего-то нового часто означает возможность продавать совершенно новую линейку продуктов и технологий, даже если эти технологии очень похожи на старые. ƒругими словами, виртуальное пространство настолько хаотично, что там легко создать что-то новое.

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

ƒобавление сложности, по-видимому, позвол€ет сети легче справл€тьс€ с будущими требовани€ми и неожиданными событи€ми, а также предоставл€ть больше услуг по меньшему набору базовых функций. ≈сли это так, то почему бы просто не построить единый протокол, работающий в одной сети, способный обрабатывать все требовани€, потенциально предъ€вл€емые к нему, и может обрабатывать любую последовательность событий, которую вы можете себе представить? ќдна сеть, работающа€ по одному протоколу, безусловно, уменьшит количество Ђдвижущихс€ частейї, с которыми приходитс€ работать сетевым администраторам, и сделает нашу жизнь проще, верно? Ќа самом деле существует целый р€д различных способов управлени€ сложностью, например:

  1. јбстрагируйтесь от сложности, чтобы построить black box вокруг каждой части системы, чтобы кажда€ часть и взаимодействие между этими част€ми были более пон€тны сразу.
  2. ѕереместите сложность в другую область Ч чтобы переместить проблему из области сетей в область приложений, кодировани€ или протокола.  ак говоритс€ в RFC1925 Ђѕроще переместить проблему (например, переместив ее в другую часть общей сетевой архитектуры), чем решить ееї
  3. ƒобавьте еще один слой сверху, чтобы рассматривать всю сложность как black box, поместив другой протокол или туннель поверх того, что уже есть. ¬озвраща€сь к RFC1925 Ђ¬сегда можно добавить еще один уровень indirectionї
  4. ѕроникнитесь сложностью, обозначьте то, что существует как Ђнаследиеї, и гонитесь за какой-то новой блест€щей вещью, котора€, как считаетс€, способна решить все проблемы гораздо менее сложным способом.
  5. »гнориру€ проблему и наде€сь, что она уйдет. јргументаци€ в пользу исключени€ Ђтолько на этот разї, так что конкретна€ бизнес-цель может быть достигнута или кака€-то проблема устранена в очень сжатые сроки, с обещанием, что проблема сложности будет решена Ђпозжеї, €вл€етс€ хорошим примером.

 аждое из этих решений, однако, имеет р€д компромиссов дл€ рассмотрени€ и управлени€.  роме того, в какой-то момент люба€ сложна€ система становитс€ хрупкой - прочной, но хрупкой. —истема €вл€етс€ надежной, но хрупкой, когда она способна устойчиво реагировать на ожидаемый набор обсто€тельств, но неожиданный набор обсто€тельств приведет к ее отказу.


ќпределение —ложности

”читыва€, что сложность необходима, инженеры должны научитьс€ управл€ть ею каким-то образом, наход€ или создава€ модель, или структуру. Ћучше всего начать построение такой модели с самого фундаментального вопроса: что означает сложность в терминах сетей? ћожно ли поставить сеть на весы и сделать так, чтобы стрелка указывала на Ђкомплексї? —уществует ли математическа€ модель, в которую можно включить конфигурации и топологию набора сетевых устройств дл€ получени€ Ђиндекса сложностиї?  ак пон€ти€ масштаба, устойчивости, хрупкости и элегантности соотнос€тс€ со сложностью? Ћучшее место дл€ начала построени€ модели Ч это пример.


—осто€ние Control Plane в зависимости от прот€женности.

„то такое прот€женность сети? ѕроще говор€, это разница между кратчайшим путем в сети и путем, который фактически принимает трафик между двум€ точками. –исунок 1 иллюстрирует эту концепцию.

–ис. 1 Ќебольша€ сеть дл€ иллюстрации состо€ни€ и прот€женности.

≈сли предположить, что стоимость каждого канала в этой сети равна 1, то кратчайший физический путь между маршрутизаторами A и C также будет кратчайшим логическим путем: [A,B, C]. ќднако что произойдет, если метрика на ссылке [A,B] изменитс€ на 3? —амый короткий физический путь по-прежнему [A,B,C], но самый короткий логический путь теперь [A,D,E,C]. –азница между кратчайшим физическим путем и кратчайшим логическим путем-это рассто€ние, которое должен пройти пакет, пересылаемый между маршрутизаторами A и CЧв этом случае прот€женность может быть вычислена как (4 [A,D,E,C])?(3 [A,B, C]), дл€ прот€женности 1.


 ак измер€етс€ прот€женность?

—пособ измерени€ прот€женности зависит от того, что €вл€етс€ наиболее важным в любой конкретной ситуации, но наиболее распространенным способом €вл€етс€ сравнение количества прыжков в сети, как это используетс€ в приведенных здесь примерах. ¬ некоторых случа€х может оказатьс€ более важным рассмотреть метрику по двум пут€м, задержку по двум пут€м или какую-то другую метрику, но важно последовательно измер€ть ее по всем возможным пут€м, чтобы обеспечить точное сравнение между пут€ми.

»ногда бывает трудно отличить физическую топологию от логической. ¬ этом случае была ли метрика канала [A,B] увеличена, потому что канал св€зи на самом деле €вл€етс€ более медленной линией св€зи? ≈сли да, то €вл€етс€ ли это примером прот€женности или примером простого приведени€ логической топологии в соответствие с физической топологией, спорно.

¬ соответствии с этим наблюдением, гораздо проще определить политику с точки зрени€ прот€женности, чем почти любым другим способом. ѕолитика Ч это люба€ конфигураци€, котора€ увеличивает прот€женность сети. »спользование Policy-Based Routing или Traffic Engineering дл€ перенаправлени€ трафика с кратчайшего физического пути на более длинный логический путь, например, дл€ уменьшени€ перегрузки в определенных каналах, €вл€етс€ политикой - она увеличивает прот€женность.

”величение прот€женности Ч это не всегда плохо. ѕонимание концепции прот€женности просто помогает нам пон€ть различные другие концепции и поставить рамки вокруг компромиссов сложности и оптимизации. —амый короткий путь, с физической точки зрени€, не всегда лучший путь.

ѕрот€женность, на этом рисунке, очень проста€Чона вли€ет на каждый пункт назначени€ и каждый пакет, проход€щий через сеть. ¬ реальном мире все гораздо сложнее. ѕрот€женность фактически приходитс€ на пару источник / приемник, что делает ее очень трудной дл€ измерени€ в масштабах всей сети.


ќпределение сложности: модель ј

“ри компонента - state, optimization, и surface, €вл€ютс€ общими практически в каждом решении по проектированию сети или протокола. »х можно рассматривать как набор компромиссов, как показано на рисунке 2 и описано в следующем списке.

  • ”величивающа€с€ оптимизаци€ всегда движетс€ в направлении большего количества состо€ний или большего количества поверхность взаимодействи€.
  • ”меньшающеес€ состо€ние всегда движетс€ в сторону меньшей оптимизации или большего количества поверхности взаимодействи€.
  • ”меньшение поверхности взаимодействи€ всегда приводит к меньшей оптимизации или большему состо€нию.

 онечно, это не железные правила; они завис€т от конкретной сети, протоколов и требований, но они, как правило, достаточно верны, чтобы сделать эту модель полезной дл€ понимани€ компромиссов в сложности.

–ис. 2 ѕлоскость возможностей

ѕоверхность взаимодействи€.

’от€ понимание определени€ состо€ние и оптимизаци€ интуитивно пон€тны, стоит потратить еще немного времени на понимание пон€ти€ поверхности взаимодействи€.  онцепци€ поверхностей взаимодействи€ трудна дл€ понимани€ прежде всего потому, что она охватывает широкий спектр идей. ¬озможно, был бы полезен данный пример. ѕредположим, что функци€, котора€:

  • ѕринимает два числа в качестве входных данных
  • ƒобавл€ет их
  • ”множает полученную сумму на 100
  • ¬озвращает результат

Ёту единственную функцию можно рассматривать как подсистему в некоторой более крупной системе. “еперь предположим, что вы разбили эту единственную функцию на две функции, одна из которых выполн€ет сложение, а друга€-умножение. ¬ы создали две более простые функции (кажда€ из которых выполн€ет только одну функцию), но вы также создали поверхность взаимодействи€ между двум€ функци€миЧвы создали две взаимодействующие подсистемы внутри системы, где раньше была только одна.

¬ качестве другого примера предположим, что у вас есть две плоскости управлени€, работающие в одной сети. ќдна из этих двух плоскостей управлени€ несет информацию о пунктах назначени€, доступных вне сети (внешние маршруты), в то врем€ как друга€ несет пункты назначени€, доступные внутри сети (внутренние маршруты). ’от€ эти две плоскости управлени€ €вл€ютс€ различными системами, они все равно будут взаимодействовать многими интересными и сложными способами. Ќапример, доступность к внешнему назначению будет об€зательно зависеть от доступности к внутренним назначени€м между кра€ми сети. Ёти две плоскости управлени€ теперь должны работать вместе, чтобы построить полную таблицу информации, котора€ может быть использована дл€ пересылки пакетов через сеть.

ƒаже два маршрутизатора, взаимодействующие в пределах одной плоскости управлени€, могут рассматриватьс€ как поверхность взаимодействи€. »менно эта широта определени€ делает очень трудным определение того, что такое поверхность взаимодействи€.

ѕоверхности взаимодействи€ не плоха€ вещь. ќни помогают инженерам и дизайнерам разделить и победить в любой конкретной области проблемы, от моделировани€ до реализации.


”правление сложностью через Wasp Waist.

Wasp waist, или модель песочных часов, используетс€ во всем мире и широко имитируетс€ в инженерном мире. ’от€ инженеры не часто сознательно примен€ют эту модель, на самом деле она используетс€ посто€нно. Ќа рис. 3 показана модель песочных часов в контексте четырехуровневой модели Department of Defense (DoD), котора€ привела к созданию пакета интернет-протоколов (IP).

Ќа нижнем уровне, физической транспортной системе, имеетс€ широкий спектр протоколов, от Ethernet до Satellite. Ќа верхнем уровне, где информаци€ распредел€етс€ и представл€етс€ приложени€м, существует широкий спектр протоколов, от протокола передачи гипертекста (HTTP) до TELNET. ќднако, когда вы перемещаетесь к середине стека, происходит забавна€ вещь: количество протоколов уменьшаетс€, создава€ песочные часы. ѕочему это работает, чтобы контролировать сложность? ≈сли мы вернемс€ к трем компонентам сложности-состо€нию, поверхности и сложности, - то обнаружим св€зь между песочными часами и сложностью.

–ис. 3 ћодель DoD и Wasp Waist
  • —осто€ние делитс€ песочными часами на два разных типа состо€ни€: информаци€ о сети и информаци€ о данных, передаваемых по сети. ¬ то врем€ как верхние уровни занимаютс€ маршалингом и представлением информации в удобной дл€ использовани€ форме, нижние уровни занимаютс€ обнаружением того, кака€ св€зь существует и каковы ее свойства на самом деле. Ќижним уровн€м не нужно знать, как форматировать кадр FTP, а верхним уровн€м не нужно знать, как переносить пакет по Ethernet - состо€ние уменьшаетс€ на обоих концах модели.
  • ѕоверхности управл€ютс€ путем уменьшени€ количества точек взаимодействи€ между различными компонентами до одного - »нтернет-протокола (IP). Ёту единственную точку взаимодействи€ можно четко определить с помощью процесса стандартизации, при этом изменени€ в одной точке взаимодействи€ тщательно регулируютс€.
  • ќптимизаци€ осуществл€етс€ путем разрешени€ одному слою проникать в другой слой, а также путем сокрыти€ состо€ни€ сети от приложений. Ќапример, TCP на самом деле не знает состо€ни€ сети, кроме того, что он может собрать из локальной информации. TCP потенциально может быть гораздо более эффективным в использовании сетевых ресурсов, но только за счет нарушени€ уровн€, которое открывает трудноуправл€емые поверхности взаимодействи€.

“аким образом, наслоение многоуровневой сетевой модели Ч это пр€ма€ попытка контролировать сложность различных взаимодействующих компонентов сети.

ќчень простой закон сложности можно сформулировать так: в любой сложной системе будут существовать наборы трехсторонних компромиссов. ќписанна€ здесь модель State/Optimization/Surface (SOS) €вл€етс€ одним из таких компромиссов. ≈ще один, более знакомый администраторам, работающим в основном с базами данных, - это Consistency/Accessibility/Partitioning (теорема CAP). ≈ще один, часто встречающийс€ в более широком диапазоне контекстов, Ч это Quick /Cost/Quality (QSQ). Ёто не компоненты сложности, а то, что можно назвать следстви€ми сложности.

јдминистраторы должны быть искусны в вы€влении такого рода компромиссных треугольников, точно понимать Ђуглыї треугольника, определ€ть, где в плоскости возможного лежит наиболее оптимальное решение, и быть в состо€нии сформулировать, почему некоторые решени€ просто невозможны или нежелательны.

≈сли вы не нашли компромиссов, вы недостаточно усердно искали Ч это хорошее эмпирическое правило, которому следует следовать во всех инженерных работах.