Как работает интернет. Для анархистов (и не только). Часть 1.5
Прошу прощения у подписчиков, что вышла такая задержка с публикацией продолжения. Надеюсь, дальше получится писать оперативнее - часть 2 уже в принципе готова, осталось вычитать. А сейчас публикую промежуточную часть 1.5, где будут рассмотрены проблемы экстенсивного роста сетей, организованных по принципам, описанным ранее.
Продолжим разбор принципов сетевых технологий.
В прошлый раз мы остановились на том, что придумали коммутатор 2-го уровня, который способен обеспечить связью до 48 человек (условно). Как нам повысить это количество — ведь в реальной сети Интернет в информобмене участвуют миллиарды устройств?
Рассмотрим для начала самый простой путь — экстенсивный.
1. Мы можем посадить в качестве коммутатора более умного и быстрого заключенного.
Правда, чтобы не просто повысить скорость информобмена, но увеличить количество подключений, ему потребуется дать камеру попросторнее — чтобы завести в нее все трубы, и было место для хранения всех досок с записями таблиц соответствия.
Поэтому, как правило, такой путь применяется все же скорее для роста скорости передачи информации, а для увеличения числа абонентов — ниже описанные.
2. Мы можем использовать так называемое стекирование.
В чем здесь суть? Представим, что вместо одной камеры-коммутатора, мы разместили рядом 2 (3,4 и более). При этом в том месте, где камеры соприкасаются (пусть это будет угол), стена убрана, и доски для записи таблиц соответствий расположены в этом освободившемся пустом пространстве так, что читать и писать на них может любой из коммутаторов.
Также, благодаря отсутствии перегородки, коммутаторы могут использовать для общения речь, а не перестукивание морзянкой. В итоге между собой они обмениваются информацией гораздо быстрее.
Чтобы начать информобмен осталось добавить только 1 элемент — теперь при записи в таблицу номера трубы (или, иначе говоря, порта) добавляется также указание на номер коммутатора, в котором эта труба подключена.
В итоге для внешнего пользователя информобмен идет так, как будто он по-прежнему общается с одним коммутатором, просто в нем стало вместо 48 — 48x (где x — количество коммутаторов) портов.
Внутри — тоже, в целом, все аналогично обычному коммутатору, за тем исключением, что при широковещательной рассылке каждый шлет сообщение не только на свои порты-трубы, но также передает сообщение (голосом, т.е. с высокой скоростью) соседним коммутаторам, и они также осуществляют рассылку по всем своим портам. Вдобавок к этому, впоследствии, уже при точечной рассылке — определяя по таблице, куда отправить сообщение — если коммутатор видит, что у порта получателя указан в качестве «родителя» другой коммутатор, он также устно (на высокой скорости, по внутренним каналам, так сказать), передает сперва сообщение соответствующему коммутатору, а тот уже транслирует его в порт-трубу.
Чем же этот путь выгоднее первого? В первую очередь тем, что позволяет гибко масштабировать сетевую инфраструктуру по мере роста нагрузки. То есть, если у вас стало в 2 раза больше пользователей, вам не надо выкидывать старый коммутатор и покупать новый — в два раза мощнее и с большим количеством портов. Просто добавьте к нему еще один в стек.
Однако надо учитывать, что далеко не все коммутаторы поддерживают стекирование — и само наличие этой возможности повышает цену. То есть при планировании сетевой инфраструктуры всегда стоит учитывать ее потенциальный рост, и выбирать соответственно — если рост не планируется или планируется незначительно — выбирается коммутатор без стекирования с небольшим запасом (20%) по свободным портам, если же рост предполагается более значительный — уже стоит рассматривать модели со стекированием.
Стекирование обладает и рядом недостатков и не позволяет решить проблему масштабирования количества пользователей выше определенного предела. Во-первых, в стек обычно объединяется не более 8-9 коммутаторов. Это связано как с ростом таблицы коммутации, так и с количеством внутреннего трафика, сложность логики передачи которого растет при увеличении количества коммутаторов. Во-вторых, для того, чтобы передавать данные на высокой скорости, надо, чтобы коммутаторы были расположены рядом. Типичная длина стекового кабеля — порядка метра. Существуют, конечно, и решения, позволяющие стекировать на расстоянии до десятков километров, однако они не слишком распространены, поскольку само по себе экстенсивное развитие ограничено рядом факторов (о чем подробнее мы поговорим ниже), и такое сильное увеличение дистанций стекирования применимо только в узких случаях.
3. Соединение нескольких коммутаторов (без стекирования!).
Как это работает? Допустим, у нас есть два крыла тюрьмы.
В первом заключенные создали себе коммутатор и общаются. Во втором крыле тоже хотят присоединиться. Но тянуть трубы в первое крыло — далеко. Да и не хватает сил уже у первого заключенного-коммутатора.
Поэтому во втором крыле организовывают свою камеру для коммутатора. И прокладывают до коммутатора первого крыла всего одну трубу (от своего коммутатора).
Таким образом, получается, что у каждого коммутатора, в целом, осталось условно по 48 труб. При этом одна из труб смотрит не на конечного пользователя, а на соседний коммутатор.
Когда первый коммутатор получает широковещательное сообщение (для примера, пусть это будет сообщение с трубы-порта 1, от пользователя с позывным Редиска), он рассылает его на все порты, в т.ч., на второй коммутатор (на порт 48). И, как мы рассказывали ранее, отмечает в своей таблице коммутации, с какого порта пришел пакет с этим позывным.
Второй коммутатор, получив от первого сообщение (допустим, у него для связи с первым также используется порт 48), поступает аналогично.
Рассылает по всем своим портам, кроме порта-источника, и помечает в таблице, что пакет от позывного Редиска приходит с порта 48. Обратите внимание, что в данном случае — фактически, на порту (трубе) 48 висит (т.е. физически подключен) не Редиска, а соседний коммутатор. Но для второго коммутатора это не важно, так как это не влияет на дальнейшую передачу данных.
Далее получатель пакета Везунчик принимает сообщение и отвечает (формирует сообщение для отправки и передает его своему коммутатору). Второй коммутатор вносит отметку в таблицу коммутации (что Везунчик висит на порту 1) и передает сообщение через трубу 48 (т.к. ранее он записал, что получатель Редиска находится именно там).
Там первый коммутатор принимает сообщение, видит, что оно предназначено Редиске, и передает его на порт 1, не забыв внести отметку о том, что Везунчик находится на порту 48.
А теперь представим, что Редиска решил послать сообщение еще и Сосиске, который также находится на втором коммутаторе. Повторится вышеописанный процесс, в итоге, в таблице коммутации первого коммутатора добавится запись, что на порту 48 висит (вдобавок к позывному Везунчик) и Сосиска. И так далее. То есть мы видим, что в данной реализации информационного обмена на каждом порту может висеть не один позывной-MAC, а сразу несколько, и разделять передаваемые сообщения между получателями уже будет конечный коммутатор, к которому они непосредственно подключены.
С одной стороны, этот метод удобен. Он позволяет по цепочке подключать новые и новые коммутаторы, наращивая объем сети.
С другой, помимо общей проблемы всех экстенсивных методов (о которой чуть ниже), он также дает следующие:
- Представим себе цепочку коммутаторов из нескольких звеньев. Представим, что пользователи первого массово начнут передавать пользователям последнего какие-то данные. При этом они загрузят не только свои коммутаторы (и линки — т.е. трубы, по которым идет передача), но и все промежуточные, замедляя работу всей сети в целом.
-
При росте сети важным требованием является не только масштабируемость, но и надежность. То есть, чтобы при обрыве одного линка (или выходе из строя части сетевых устройств), не происходило нарушение связи.
При использовании одного мощного коммутатора или при стекировании (когда оба коммутатора работают как один) можно (если коммутаторы это поддерживают) просто подключаться через две трубы сразу (в случае стека лучше так, чтобы они шли к разным коммутаторам, что даст дополнительно резервирование по оборудованию). Они при этом будут работать как одна труба удвоенной ширины (эта технология называется Link Aggregation), и сохранять связь при обрыве любой одной из них.
В случае же 3 метода, подключение нескольких линков приведет к образованию петли, что провоцирует широковещательный шторм (Broadcast storm).
Как это происходит: когда коммутатор получает широковещательное сообщение, он посылает его на все порты, кроме порта получения. Представим теперь, что между коммутаторами два линка. Один из них получает широковещательное сообщение, и рассылает его по всем портам. Второй получает это сообщение с двух портов и также рассылает его по всем портам. Но из-за того, что для него эти два сообщения получены с разных портов, и, как следствие, рассматриваются как уникальные, он также пошлет их и обратно на первый коммутатор (пришедшее по 1 линку — во второй, по 2 — в первый). В итоге сообщение передается по коммутаторам бесконечно, отъедая производительность, и по мере роста количества таких сообщений (а он происходит очень быстро) — приводя к полной остановке коммутаторов из-за бесконечной обработки «мусорных» сообщений.
Разумеется, придуманы механизмы защиты от таких проблем — так называемые Spanning-tree protocol-ы, которые отслеживают возникновение петель автоматически, блокируя один из портов, и активируя его снова, если связь по основному прервалась. Однако данные технологии конфликтуют с другими (к примеру, с Portfast), поэтому петли все равно иногда могут возникать. А также существуют, в зависимости от редакции протокола STP, еще и ощутимые задержки при переключении. А чем больше сеть — тем чаще будут возникать какие-то проблемы, и тем больше времени она будет в состоянии «переключения», когда старый линк уже не работает, а новый — еще не включился.
Какая же общая проблема у всех описанных выше способов и почему необходим качественный скачок?
Во-первых, это рост таблиц коммутации. При экстенсивном росте каждый коммутатор (будь то стек или нет) должен знать информацию о всех абонентах.
Во-вторых, это проблемы широковещательных рассылок. Чем больше абонентов в сети, тем больше идет запросов с заголовком «всем». Если очень обще, то при превышении числа абонентов (грубо говоря) 255, основной нагрузкой коммутаторов становится пересылка arp-запросов «а кто такой-то такой-то?».
Проблема в том, что эти сообщения транслируются на все порты и на все присоединенные коммутаторы, фактически блокируя как межкоммутаторные связи, так и точки подключения абонентов.
Возвращаясь к нашей аналогии, по батареям будет раздаваться непрерывный стук, причем 99% от сообщений каждый из получателей будет просто отбрасывать.
В-третьих — это проблемы балансировки и резервирования нагрузки (подробно на этом сейчас останавливаться не будем).
Чтобы уйти от этих проблем, необходим качественный скачок. Как его сделать — мы рассмотрим в следующей статье.
-----------------------------------------------------------------
Свои статьи я публикую также на сайте,
в группе Вконтакте
и Телеграмм-канале - если кому то вдруг будет удобнее подписаться там :-).