ћерион Ќетворкс

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

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

  • —осто€ние: количество состо€ний и скорость, с которой измен€етс€ состо€ние в сети (особенно в плоскости управлени€).
  • ќптимизаци€: оптимальное использование сетевых ресурсов, включа€ такие вещи, как трафик, следующий по кратчайшему пути через сеть.
  • ѕоверхность: количество слоев, глубина их взаимодействи€ и широта взаимодействи€.

ѕоверхности взаимодействи€ и группы св€зей общих рисков

 ажда€ система виртуализации, когда-либо задуманна€, реализованна€ и развернута€, создает в некотором роде общий риск. Ќапример, рассмотрим одну линию, по которой передаетс€ несколько виртуальных каналов, каждый из которых передает трафик. ƒолжно быть очевидным (на самом деле тривиальным) наблюдение, что в случае отказа одного физического канала произойдет сбой всех виртуальных каналов.  онечно, вы можете просто перенаправить виртуальные каналы на другой физический канал. ѕравильно? ћожет быть, а может и нет. –исунок 1 иллюстрирует это.

— точки зрени€ A и D, есть две линии, доступные через B и C, кажда€ из которых обеспечивает независимое соединение между хостом и сервером. ¬ действительности, однако, и провайдер 1, и провайдер 2 приобрели виртуальные каналы через единственное соединение у провайдера 3.  огда единственное соединение в сети провайдера 3 выходит из стро€, трафик может быть перенаправлен с основного пути через провайдера 1 на путь через провайдера. 2, но поскольку оба канала используют одну и ту же физическую инфраструктуру, ни одна из них не сможет передавать трафик.

√руппы св€зей общих рисков

√овор€т, что эти два звена в этой ситуации раздел€ют одну общую судьбу, потому что они €вл€ютс€ частью Shared Risk Link Group (SRLG). ћожно найти и обойти SRLG или ситуации с shared fate, но это усложн€ет плоскость управлени€ и/или управление сетью. Ќапример, невозможно обнаружить эти shared fate без ручного тестировани€ различных ситуаций отказа на физическом уровне или изучени€ сетевых карт, чтобы найти места, где несколько виртуальных каналов проход€т по одному и тому же физическому каналу. ¬ ситуации, описанной на рисунке 1, найти ситуацию с shared fate было бы почти невозможно, поскольку ни один из провайдеров, скорее всего, не скажет вам, что использует линию от второго провайдера, показанного на рисунке как провайдер 3, дл€ предоставлени€ услуг.

 ак только эти ситуации с shared fate обнаружены, необходимо предприн€ть некоторые действи€, чтобы избежать серьезного сбо€ в работе сети. ќбычно дл€ этого требуетс€ либо вводить информацию в процесс проектировани€, либо усложн€ть дизайн, либо вводить информацию в плоскость управлени€ (см. RFC8001 в качестве примера типа сигнализации, необходимой дл€ управлени€ группами SRLG в плоскости управлени€, спроектированной трафиком). ѕо сути, проблема сводитс€ к следующему набору утверждений:

  • ¬иртуализаци€ - это форма абстракции.
  • јбстракци€ удал€ет информацию о состо€нии сети с целью снижени€ сложности или предоставлени€ услуг за счет реализации политики.
  • Ћюбое нетривиальное сокращение информации о состо€нии сети так или иначе снизит оптимальное использование ресурсов.

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


ѕоверхности взаимодействи€ и наложенные плоскости управлени€

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

Ќа рисунке 2:

  •  аждый маршрутизатор в сети, включа€ B, C, D и E, использует две плоскости управлени€ (или, если это проще, протоколы маршрутизации, отсюда протокол 1 и протокол 2 на рисунке).
  • ѕротокол 1 (оверлей) зависит от протокола 2 (базовый) дл€ обеспечени€ доступности между маршрутизаторами, на которых работает протокол 1.
  • ѕротокол 2 не содержит информации о подключенных устройствах, таких как A и F; вс€ эта информаци€ передаетс€ в протоколе 1.
  • ѕротокол 1 требует гораздо больше времени дл€ схождени€, чем протокол 2.
  • Ѕолее простой путь от B к E проходит через C, а не через D.

”читыва€ этот набор протоколов, предположим, что C на рисунке 2 удален из сети, двум управл€ющим плоскост€м разрешено сходитьс€, а затем C снова подключаетс€ к сети.  аков будет результат? ѕроизойдет следующее:

  • ѕосле удалени€ C сеть снова объединитс€ с двум€ пут€ми в локальной таблице маршрутизации в B:
    • F доступен через E.
    • E доступен через D.
  • ѕосле повторного подключени€ C к сети протокол 2 быстро сойдетс€.
  • ѕосле повторной конвергенции протокола 2 лучший путь к E с точки зрени€ B будет через C.
  • —ледовательно, у B теперь будет два маршрута в локальной таблице маршрутизации:
    • F доступен через E.
    • E достижимо через C.
  • B перейдет на новую информацию о маршрутизации и, следовательно, будет отправл€ть трафик к F через C до того, как протокол 1 сойдетс€, и, следовательно, до того, как C узнает о наилучшем пути к F.
  • — момента, когда B начинает пересылку трафика, предназначенного дл€ F в C, и момента, когда протокол 1 сойдетс€, трафик, предназначенный дл€ F, будет отброшен.

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

Ќаложенные плоскости управлени€, виртуализаци€ и поверхности взаимодействи€
ѕримечание: Ётот пример описывает фактическое взаимодействие конвергенции между IS-IS и BGP, или протоколом Open Shortest Path First (OSPF) и BGP. „тобы решить эту проблему, более быстрый протокол настроен на ожидание, пока BGP не сойдетс€, прежде чем устанавливать какие-либо маршруты в локальной таблице маршрутизации.

—кидки 50% в Merion Academy

¬ыбрать курс