Challenges in Separating the Data and Control Planes (подстрочник на русском языке)

Добро пожаловать на курс по программно-определяемым сетям. В этом уроке мы продолжаем обсуждение разделения плоскости управления и данных, и в частности, мы говорим о трудностях, связанных с разделением плоскости данных и управления. Мы рассмотрим несколько проблем, связанных с разделением плоскости управления и данных. Включая масштабируемость, надежность и согласованность. И мы поговорим о подходах к решению этих задач в виде двух разных систем. Платформа управления маршрутизацией и ONIX. Давайте сначала рассмотрим некоторые проблемы масштабируемости, с которыми сталкивается платформа управления маршрутизацией, и подходы, используемые этой платформой для решения некоторых из этих проблем масштабируемости. Таким образом, одна из проблем, с которой сталкивается RCP, заключается в том, что он должен хранить маршруты и вычислять решения о маршрутизации для каждого маршрутизатора в автономной системе. И одна автономная система может иметь от сотен до тысяч маршрутизаторов. Таким образом, это потенциально много, много таблиц маршрутизации и множество вычислений маршрутизации, все выполняется на одном узле. Тогда как раньше все эти вычисления распределялись по самим маршрутизаторам. Таким образом, некоторые принципы масштабируемости из дизайна RCP. Во-первых, это устранить избыточность. Вместо того, чтобы хранить таблицу маршрутизации для каждого маршрутизатора в автономной системе. RCP хранит одну копию каждого маршрута и если эти маршруты дублируются между маршрутизаторами и автономной системой, как это обычно бывает. Эта избыточность может быть представлена хранением указателей в общей структуре данных. Второй принцип заключается в ускорении поиска путем поддержания индексов для идентификации конкретных маршрутизаторов, которые могут быть осуществлены в результате изменения условий сети. Например, объявление нового маршрута или сбоя узла или канала. Поэтому при возникновении определенного события RCP необходимо вычислить только новую информацию о маршрутизации или таблицы маршрутизации для маршрутизаторов, на которые влияет это изменение. Вместо того, чтобы пересчитать состояние всей сети. Наконец, RCP решает некоторые проблемы масштабируемости, просто выполняя маршрутизацию для всех протоколов маршрутизации в сети и просто решает сосредоточиться на выполнении только междоменной маршрутизации. Сетевой контроллер ONIX применяет несколько связанных принципов для решения проблем масштабируемости. Во-первых, это разбиение на разделы, в результате чего контроллер ONIX может фактически отслеживать только подмножество общей сетевой информационной базы. И состояние сети в сети. А затем применять различные протоколы согласованности для поддержания согласованности между различными разделами. Контроллер ONIX использует две различные модели консистенции. Одним из них является сильная модель согласованности, которая гарантирует, что различные реплики сильно согласованы за счет некоторой производительности. Другой — более слабая модель согласованности. Это более эффективно в том, что касается передачи информации быстрее. Второй принцип масштабируемости - агрегация. Таким образом, дизайн Onix по существу описывает понятие иерархического набора контроллеров. Например, наличие контроллера Onix для отдела или здания в более крупной корпоративной сети. И иметь один суперконтроллер ONIX, который эффективно контролирует эти суб-контроллеры для общего домена. Давайте теперь рассмотрим, как эти системы решают вторую проблему: проблему надежности. Таким образом, один конкретный подход к rel-, надежности заключается в том, чтобы просто реплицировать. Таким образом, дизайн RCP выступает за наличие горячего резерва, при котором несколько идентичных RCP-серверов по существу работают параллельно. Резервное копирование или резервное RCP может взять на себя в случае сбоя основного сервера. Таким образом, идея заключается в том, что сеть будет запускать независимые реплики RCP, при этом каждая реплика имеет свой собственный канал маршрутов от всех маршрутизаторов автономной системы. Теперь, если каждая реплика получает то же самое увеличение и запускает тот же вывод маршрутизации, то это должно быть так, что выход или результирующее состояние, что каждый из этих RCP будет отталкиваться назад. В маршрутизаторах должны быть точно такие же, потому что входные данные и алгоритм точно такие же. Таким образом, в случае подхода Hot Spare на самом деле нет необходимости в протоколе согласованности, если обе реплики всегда видят одну и ту же информацию. Однако существуют потенциальные проблемы согласованности, если разные реплики видят различную информацию. Посмотрим, как это может быть. Итак, вот два RCP. Предположим, что они видят различную информацию и, как результат, вычисляют разные результаты. Или желаемое состояние таблицы маршрутизации для маршрутизаторов A и B в этой автономной системе. Таким образом, RCP слева может вычислить исходящий маршрут для маршрутизатора A, то есть использовать исходящий маршрутизатор D для достижения определенного места назначения и, следовательно, использовать маршрутизатор B в качестве следующего перехода для выхода маршрутизатора D. Теперь аналогичным образом второй RCP, RCP справа может установить конфликтующий состояние в маршрутизатор B, который говорит: используйте исходящий маршрутизатор C. Чтобы достичь этого назначения, и вы используете a в качестве следующего верха для достижения выходного маршрутизатора C. Теперь вы можете видеть, что если эти две реплики устанавливают это соответствующее состояние в маршрутизаторы A и B, то у нас есть цикл пересылки между маршрутизатором A и маршрутизатор B, потому что при попытке добраться до этого места назначения,. Маршрутизатор A будет использовать золотой маршрут, чтобы попытаться выйти через маршрутизатор D, а маршрутизатор B будет использовать серый маршрут, чтобы попытаться выйти через маршрутизатор C. И когда каждый из этих маршрутизаторов получит пакеты для этого назначения. От его соседа он просто собирается отскочить пакеты назад и вперед. Поэтому мы хотим, чтобы назначения маршрутов были согласованными даже при наличии сбоев и разделов. Теперь мы ранее просто сказали, что если каждый RCP получает один и тот же вход. И запускает тот же алгоритм. Тогда вывод должен быть последовательным, и мы хотим каким-то образом гарантировать это. Теперь, к счастью, внутренний протокол шлюза, основанный на наводнении, такой как OCPF или ISIS, как мы узнали в нашем сетевом курсе. По существу означает, что каждая из этих реплик уже знает, к каким разделам она подключена. Если RCP участвует в протоколе маршрутизации внутри домена или IGP, то он видит полное состояние связи этого раздела. И этой информации, которую он получает, достаточно, чтобы убедиться, что RCP вычисляет только данные таблицы маршрутизации или состояние маршрутизации для маршрутизаторов в разделе, к которому он подключен. И этого достаточно, чтобы гарантировать правильность. Посмотрим, почему. Предположим, что у нас есть сетевой раздел , где маршрутизаторы в разделе не могут видеть или не могут пересылать трафик на маршрутизаторы второго раздела. И наоборот. Теперь в этом случае решением было бы иметь только одно состояние RCP, от маршрутизаторов в каждом из этих разделов при назначении маршрутов. Например, чтобы назначить маршруты маршрутизаторам в первом разделе, RCP будет использовать только набор потенциальных маршрутов, полученный от маршрутизаторов в первом разделе. Он не будет использовать какие-либо маршруты из маршрутизаторов, которые он узнал из раздела 2. И одного этого на самом деле достаточно, чтобы гарантировать последовательную пересылку. Вы можете интуитивно понять, почему, так как, например, если RCP никогда не назначает маршрутизатору маршрут, полученный для раздела 2 , то фактически раздел один и второй просто действуют как отдельные сети с общей платформой управления маршрутизацией. Предположим, теперь, когда у нас есть несколько RCP, что мы фактически реплицировали RCP, но сама сеть имеет несколько разделов. Теперь вы можете подумать, что у нас есть более серьезная проблема, потому что у вас могут быть случаи, когда есть разделы. Они доступны как RCP, так и могут быть видны обоими RCP. Но у вас есть другие, которые доступны только подмножествами, которые могут быть не перекрывающимися. Ну, подход здесь заключается в том, чтобы просто убедиться, что RCP получает одно и то же состояние от каждого раздела, которое они могут достичь. Таким образом, IGP обеспечивает полную видимость и подключение для каждого из этих разделов, и если RCP действует только на раздел, если он имеет полное состояние для этого раздела. Тогда гарантировано, что маршруты, которые он назначает для этого раздела, будут согласованными. Другими словами, никаких петель пересылки не будет. Давайте посмотрим, как ONIX решает проблемы надежности. Таким образом, ONIX говорит о различных типах сбоев, которые могут возникнуть в сети. Во-первых, это сетевые сбои. В этом случае ONIX просто предполагает, что ответственность за обнаружение и восстановление после этих сбоев лежит на приложении. Теперь , если сбой сети влияет на достижимость ONIX. Конструкция предполагает, что использование надежного протокола или многопутевой маршрутизации и т. д. может помочь гарантировать, что контроллер ONIX остается доступным даже в случае сбоя сети. Если сам ONIX терпит неудачу, решение состоит в том, чтобы применить репликацию, а затем использовать распределенный протокол координации между этими репликами. Теперь, поскольку ONIX был разработан для гораздо более общего набора приложений, чем платформа управления маршрутизацией, необходим более сложный протокол распределенной координации. Некоторые детали этих координационных протоколов обсуждаются в документе, на который была сделана ссылка на первоначальном слайде. Там , где мы разговариваем, были ли мы представлены ONIX в этой лекции. Таким образом, разделение плоскости управления и данных сопряжено с тремя существенными проблемами. Один из них — масштабируемость. В частности, один контроллер должен теперь принимать решения о маршрутизации или различные решения о плоскости управления от имени многих, многих элементов сети. Раньше каждый выполнял эти вычисления самостоятельно для себя. Вторая проблема — это надежность. Это гарантирует правильную работу при сбое сети или сбое самого контроллера. Третья проблема — это последовательность. Мы обеспечиваем согласованность между несколькими репликами контроллеров. В частности, в случае сетевых разделов или сбоев. Итак, мы экспортируем каждую из этих задач в деталях и рассказываем о различных методах, включая иерархию, агрегацию и различные умные методы управления состоянием и распределения, которые различные системы, такие как RCP и оникс, использовали для решения этих проблем. Каждый конкретный контроллер решает эти проблемы по-разному, но многие из этих принципов применяются в различных конструкциях и реализациях контроллеров.