Что такое масштабируемость сети
Видение отказоустойчивой, надежной, масштабируемой сети передачи данных
Воодушевленный философией сетевых технологий, технологиями передачи данных, да и вообще всем тем, что объясняет, как все работает, решаюсь написать ряд статей о том, что является эталоном сетевых решений, качественной реализацией или настройкой, или что подобным не является, но в современности присутствует, и жутко раздражает.
Что же в этот раз.
В видении построения сетей компании Cisco существует понятие трехуровневая модель.
Трехуровневая модель сети представляет собой некую иерархическую структуру передачи данных не в терминах протоколов или моделей (типа модели OSI или TCP/IP), а в терминах функционирования абстрактных элементов сети.
Из названия очевидно, что все элементы сети делятся на три так называемых уровня. Это деление позволяет строить отказоустойчивые, надежные, масштабируемые сети передачи данных. Роль уровней скорее логическая, и не обязательно существует физическая привязка к конкретному оборудованию. 
Базовый уровень (Core Layer)
Является ядром сети. Единственное, что он должен выполнять — молниеносно перенаправлять пакеты из одного сегмента в другой. Базовый уровень отвечает только за скоростную коммутацию трафика, он не отвечает за маршрутизацию. Исходя из этого, базовый уровень нужно обеспечить высокой степенью отказоустойчивости и надежности. Обычно дублируют устройства, работающие на базовом уровне. Рассмотрим, к примеру Cisco WS-C6503-E.
Уровень распределения (Distribution Layer)
Представляет собой «прослойку» между уровнем доступа и уровнем ядра (базовым уровнем). Именно на этом уровне осуществляется контроль над сетевой передачей данных. Также можно создавать широковещательные домены, создавать VLAN’ы, если необходимо, а так же внедрять различные политики (безопасности и управления). На уровне распределения может осуществляться правило обращения к уровню ядра. Приведу некоторые особенности и рекомендации при проектировании уровня распределения, которые выделяют ведущие производители сетевого оборудования.
Уровень доступа (Access Layer)
Важно!
Необходимо при построении сети придерживаться правила, чтобы функции одного уровня не выполнял другой и наоборот.
Естественно, что такая модель приемлема для сети крупного предприятия, в интересах которого функционирование ее должным образом. Немало нужно затратить сил и, времени и средств, чтобы выработать проект, внедрить и обслуживать такую сеть. Но зато это стоит того!
Что такое масштабируемость сети
Расширяемость и масштабируемость.
Расширяемость (extensibility) означает возможность сравнительно легкого добавления отдельных элементов сети (пользователей, компьютеров, приложений, служб), наращивания длины сегментов сети и замены существующей аппаратуры более мощной. При этом принципиально важно, что легкость расширения системы иногда может обеспечиваться в весьма ограниченных пределах. Например, локальная сеть Ethernet, построенная на основе одного сегмента толстого коаксиального кабеля, обладает хорошей расширяемостью, в том смысле, что позволяет без труда подключать новые станции. Однако такая сеть имеет ограничение на число станций — оно не должно превышать 30–40. Хотя сеть допускает физическое подключение к сегменту и большего числа станций (до 100), но при этом чаще всего резко снижается производительность сети. Наличие такого ограничения и является признаком плохой масштабируемости системы при хорошей расширяемости.
Масштабируемость (scalability) означает, что сеть позволяет наращивать количество узлов и протяженность связей в очень широких пределах, при этом производительность сети не ухудшается. Для обеспечения масштабируемости сети приходится применять дополнительное коммуникационное оборудование и специальным образом структурировать сеть. Например, хорошей масштабируемостью обладает многосегментная сеть, построенная с использованием коммутаторов и маршрутизаторов и имеющая иерархическую структуру связей. Такая сеть может включать несколько тысяч компьютеров и при этом обеспечивать каждому пользователю сети нужное качество обслуживания.
Прозрачность (transparency) сети достигается в том случае, когда сеть представляется пользователям не как множество отдельных компьютеров, связанных между собой сложной системой кабелей, а как единая традиционная вычислительная машина с системой разделения времени.
Прозрачность может быть достигнута на двух различных уровнях — на уровне пользователя и на уровне программиста. На уровне пользователя прозрачность означает, что для работы с удаленными ресурсами он использует те же команды и привычные процедуры, что и для работы с локальными ресурсами. На программном уровне прозрачность заключается в том, что приложению для доступа к удаленным ресурсам требуются те же вызовы, что и для доступа к локальным ресурсам. Прозрачности на уровне пользователя достичь проще, так как все особенности процедур, связанные с распределенным характером системы, скрываются от пользователя программистом, который создает приложение. Прозрачность на уровне приложения требует сокрытия всех деталей распределенности средствами сетевой операционной системы.
Прозрачность — свойство сети скрывать от пользователя детали своего внутреннего устройства, что упрощает работу в сети.
Концепция прозрачности применима к различным аспектам сети. Например, прозрачность расположения означает, что от пользователя не требуется знать местонахождение программных и аппаратных ресурсов, таких как процессоры, принтеры, файлы и базы данных. Имя ресурса не должно включать информацию о месте его расположения, поэтому имена типа mashine1:prog.c или \\ftp_serv\pub прозрачными не являются. Аналогично, прозрачность перемещения означает, что ресурсы могут свободно перемещаться из одного компьютера в другой без изменения имен. Еще одним из возможных аспектов прозрачности является прозрачность параллелизма, которая заключается в том, что процесс распараллеливания вычислений происходит автоматически, без участия программиста, при этом система сама распределяет параллельные ветви приложения по процессорам и компьютерам сети. В настоящее время нельзя сказать, что свойство прозрачности в полной мере присуще многим вычислительным сетям, это скорее цель, к которой стремятся разработчики современных сетей.
Поддержка разных видов трафика
Компьютерные сети изначально предназначались для совместного доступа к ресурсам компьютеров: файлам, принтерам и т. п. Трафик, создаваемый этими традиционными службами компьютерных сетей, имеет свои особенности и существенно отличается от трафика сообщений в телефонных сетях или, например, в сетях кабельного телевидения. Однако в 90-е годы в компьютерные сети проник трафик мультимедийных данных, представляющих в цифровой форме речь и видеоизображение. Компьютерные сети стали использоваться для организации видеоконференций, обучения на основе видеофильмов и т. п. Естественно, что для динамической передачи мультимедийного трафика требуются иные алгоритмы и протоколы, и, соответственно, другое оборудование. Хотя доля мультимедийного трафика пока невелика, он уже начал проникать как в глобальные, так и в локальные сети, и этот процесс, очевидно, будет активно продолжаться.
Главной особенностью трафика, образующегося при динамической передаче голоса или изображения, является наличие жестких требований к синхронности передаваемых сообщений. Для качественного воспроизведения непрерывных процессов, которыми являются звуковые колебания или изменения интенсивности света в видеоизображении, необходимо получение измеренных и закодированных амплитуд сигналов с той же частотой, с которой они были измерены на передающей стороне. При запаздывании сообщений будут наблюдаться искажения.
В то же время трафик компьютерных данных характеризуется крайне неравномерной интенсивностью поступления сообщений в сеть при отсутствии жестких требований к синхронности доставки этих сообщений. Например, доступ пользователя, работающего с текстом на удаленном диске, порождает случайный поток сообщений между удаленным и локальным компьютерами, зависящий от действий пользователя, причем задержки при доставке в некоторых (достаточно широких с компьютерной точки зрения) пределах мало влияют на качество обслуживания пользователя сети. Все алгоритмы компьютерной связи, соответствующие протоколы и коммуникационное оборудование были рассчитаны именно на такой “пульсирующий” характер трафика, поэтому необходимость передавать мультимедийный трафик требует внесения принципиальных изменений, как в протоколы, так и в оборудование. Сегодня практически все новые протоколы в той или иной степени предоставляют поддержку мультимедийного трафика.
Особую сложность представляет совмещение в одной сети традиционного компьютерного и мультимедийного трафика. Передача исключительно мультимедийного трафика компьютерной сетью хотя и связана с определенными сложностями, но доставляет меньше хлопот. А вот сосуществование двух типов трафика с противоположными требованиями к качеству обслуживания является намного более сложной задачей. Обычно протоколы и оборудование компьютерных сетей относят мультимедийный трафик к факультативному, поэтому качество его обслуживания оставляет желать лучшего. Сегодня затрачиваются большие усилия по созданию сетей, которые не ущемляют интересы одного из типов трафика. Наиболее близки к этой цели сети на основе технологии ATM, разработчики которой изначально учитывали случай сосуществования разных типов трафика в одной сети.
Управляемость
В идеале средства управления сетями представляют собой систему, осуществляющую наблюдение, контроль и управление каждым элементом сети — от простейших до самых сложных устройств, при этом такая система рассматривает сеть как единое целое, а не как разрозненный набор отдельных устройств.
Совместимость или интегрируемость означает, что сеть может включать в себя разнообразное программное и аппаратное обеспечение, то есть в ней могут сосуществовать различные операционные системы, поддерживающие разные стеки коммуникационных протоколов, и работать аппаратные средства и приложения от разных производителей. Сеть, состоящая из разнотипных элементов, называется неоднородной или гетерогенной, а если гетерогенная сеть работает без проблем, то она является интегрированной. Основной путь построения интегрированных сетей — использование модулей, выполненных в соответствии с открытыми стандартами и спецификациями.
Качество обслуживания
Качество обслуживания ( Quality of Service, QoS ) определяет количественные оценки вероятности того, что сеть будет передавать определенный поток данных между двумя узлами в соответствии с потребностями приложения или пользователя.
Например, при передаче голосового трафика через сеть под качеством обслуживания чаще всего понимают гарантии того, что голосовые пакеты будут доставляться сетью с задержкой не более N мс, при этом вариация задержки не превысит M мс, и эти характеристики станут выдерживаться сетью с вероятностью 0,95 на определенном временном интервале. То есть приложению, которое передает голосовой трафик, важно, чтобы сеть гарантировала соблюдение именно этого приведенного выше набора характеристик качества обслуживания. Файловому сервису нужны гарантии средней полосы пропускания и расширения ее на небольших интервалах времени до некоторого максимального уровня для быстрой передачи пульсаций. В идеале сеть должна гарантировать особые параметры качества обслуживания, сформулированные для каждого отдельного приложения. Однако по понятным причинам разрабатываемые и уже существующие механизмы QoS ограничиваются решением более простой задачи — гарантированием неких усредненных требований, заданных для основных типов приложений.
Чаще всего параметры, фигурирующие в разнообразных определениях качества обслуживания, регламентируют следующие показатели работы сети:
Качество обслуживания гарантируется для некоторого потока данных. Напомним, что поток данных — это последовательность пакетов, имеющих некоторые общие признаки, например адрес узла-источника, информация, идентифицирующая тип приложения (номер порта TCP/UDP) и т. п. К потокам применимы такие понятия, как агрегирование и дифференцирование. Так, поток данных от одного компьютера может быть представлен как совокупность потоков от разных приложений, а потоки от компьютеров одного предприятия агрегированы в один поток данных абонента некоторого провайдера услуг.
Механизмы поддержки качества обслуживания сами по себе не создают пропускной способности. Сеть не может дать больше того, что имеет. Так что фактическая пропускная способность каналов связи и транзитного коммуникационного оборудования — это ресурсы сети, являющиеся отправной точкой для работы механизмов QoS. Механизмы QoS только управляют распределением имеющейся пропускной способности в соответствии с требованиями приложений и настройками сети. Самый очевидный способ перераспределения пропускной способности сети состоит в управлении очередями пакетов.
Поскольку данные, которыми обмениваются два конечных узла, проходят через некоторое количество промежуточных сетевых устройств, таких как концентраторы, коммутаторы и маршрутизаторы, то поддержка QoS требует взаимодействия всех сетевых элементов на пути трафика, то есть “из-конца-в-конец” (“end-to-end“, “e2e“). Любые гарантии QoS настолько соответствуют действительности, насколько их обеспечивает наиболее “слабый” элемент в цепочке между отправителем и получателем. Поэтому нужно четко понимать, что поддержка QoS только в одном сетевом устройстве, пусть даже и магистральном, может лишь весьма незначительно улучшить качество обслуживания или же совсем не повлиять на параметры QoS.
Реализация в компьютерных сетях механизмов поддержки QoS является сравнительно новой тенденцией. Долгое время компьютерные сети существовали без таких механизмов, и это объясняется в основном двумя причинами. Во-первых, большинство приложений, выполняемых в сети, были “нетребовательными”, то есть для таких приложений задержки пакетов или отклонения средней пропускной способности в достаточно широком диапазоне не приводили к значительной потере функциональности. Примерами “нетребовательных” приложений являются наиболее распространенные в сетях 80-х годов приложения электронной почты или удаленного копирования файлов.
Во-вторых, сама пропускная способность 10-мегабитных сетей Ethernet во многих случаях не была дефицитом. Так, разделяемый сегмент Ethernet, к которому было подключено 10-20 компьютеров, изредка копирующих небольшие текстовые файлы, объем которых не превышает несколько сотен килобайт, позволял трафику каждой пары взаимодействующих компьютеров пересекать сеть так быстро, как требовалось породившим этот трафик приложениям.
В результате большинство сетей работало с тем качеством транспортного обслуживания, которое обеспечивало потребности приложений. Правда, никаких гарантий относительно контроля задержек пакетов или пропускной способности, с которой пакеты передаются между узлами, в определенных пределах эти сети не давали. Более того, при временных перегрузках сети, когда значительная часть компьютеров одновременно начинала передавать данные с максимальной скоростью, задержки и пропускная способность становились такими, что работа приложений давала сбой — шла слишком медленно, с разрывами сессий и т. п.
Существует два основных подхода к обеспечению качества работы сети. Первый состоит в том, что сеть гарантирует пользователю соблюдение некоторой числовой величины показателя качества обслуживания. Например, сети frame relay и ATMмогут гарантировать пользователю заданный уровень пропускной способности. При втором подходе (best effort) сеть старается по возможности более качественно обслужить пользователя, но ничего при этом не гарантирует.
Транспортный сервис, который предоставляли такие сети, получил название “best effort”, то есть сервис “с максимальными усилиями” (или “по возможности” ). Сеть старается обработать поступающий трафик как можно быстрее, но при этом никаких гарантий относительно результата не дает. Примерами может служить большинство технологий, разработанных в 80-е годы:Ethernet, Token Ring, IP, X.25. Сервис “с максимальными усилиями” основан на некотором справедливом алгоритме обработки очередей, возникающих при перегрузках сети, когда в течение некоторого времени скорость поступления пакетов в сеть превышает скорость продвижения этих пакетов. В простейшем случае алгоритм обработки очереди рассматривает пакеты всех потоков как равноправные и продвигает их в порядке поступления (First In — First Out, FIFO). В том случае, когда очередь становится слишком большой (не умещается в буфере), проблема решается простым отбрасыванием новых поступающих пакетов.
Очевидно, что сервис “с максимальными усилиями” обеспечивает приемлемое качество обслуживания только в тех случаях, когда производительность сети намного превышает средние потребности, то есть является избыточной. В такой сети пропускная способность достаточна даже для поддержания трафика пиковых периодов нагрузки. Также очевидно, что такое решение не экономично — по крайней мере, по отношению к пропускным способностям сегодняшних технологий и инфраструктур, особенно для глобальных сетей. Тем не менее, построение сетей с избыточной пропускной способностью, будучи самым простым способом обеспечения нужного уровня качества обслуживания, иногда применяется на практике. Например, некоторые провайдеры услуг сетей TCP/IP предоставляют гарантию качественного обслуживания, постоянно поддерживая определенный уровень превышения пропускной способности своих магистралей по сравнению с потребностями клиентов.
В условиях, когда многие механизмы поддержки качества обслуживания только разрабатываются, использование для этих целей избыточной пропускной способности часто оказывается единственно возможным, хотя и временным решением.
Что такое масштабируемость сети
Повсеместная связь через Интернет быстро стала таким же обычным делом, как возможность послать кому угодно в мире письмо по почте. Помня это, мы говорим, что масштабируемость — это одна из наиболее важных задач при проектировании распределенных систем.
Масштабируемость системы может измеряться по трем различным показателям. Во-первых, система может быть масштабируемой по отношению к ее размеру, что означает легкость подключения к ней дополнительных пользователей и ресурсов. Во-вторых, система может масштабироваться географически, то есть пользователи и ресурсы могут быть разнесены в пространстве. В-третьих, система может быть масштабируемой в административном смысле, то есть быть проста в управлении при работе во множестве административно независимых организаций. К сожалению, система, обладающая масштабируемостью по одному или нескольким из этих параметров, при масштабировании часто дает потерю производительности.
Если система нуждается в масштабировании, необходимо решить множество разнообразных проблем. Сначала рассмотрим масштабирование по размеру. Если возникает необходимость увеличить число пользователей или ресурсов, мы нередко сталкиваемся с ограничениями, связанными с централизацией служб, данных и алгоритмов (табл. 1.2). Так, например, многие службы централизуются потому, что при их реализации предполагалось наличие в распределенной системе только одного сервера, запущенного на конкретной машине. Проблемы такой схемы очевидны: при увеличении числа пользователей сервер легко может стать узким местом системы. Даже если мы обладаем фактически неограниченным запасом по мощности обработки и хранения данных, ресурсы связи с этим сервером в конце концов будут исчерпаны и не позволят нам расти дальше.
Таблица 1.2. Примеры ограничений масштабируемости
Один сервер на всех пользователей
Единый телефонный справочник, доступный в режиме подключения
Организация маршрутизации на основе полной информации
К сожалению, использование единственного сервера время от времени неизбежно. Представьте себе службу управления особо конфиденциальной информацией, такой как истории болезни, банковские счета, кредиты и т. п. В подобных случаях необходимо реализовывать службы на одном сервере в отдельной хорошо защищенной комнате и отделять их от других частей распределенной системы посредством специальных сетевых устройств. Копирование информации, содержащейся на сервере, в другие места для повышения производительности даже не обсуждается, поскольку это сделает службу менее стойкой к атакам злоумышленников.
И, наконец, централизация алгоритмов — это тоже плохо. В больших распределенных системах гигантское число сообщений необходимо направлять по множеству каналов. Теоретически для вычисления оптимального пути необходимо получить полную информацию о загруженности всех машин и линий и по алгоритмам из теории графов вычислить все оптимальные маршруты. Эта информация затем должна быть раздана по системе для улучшения маршрутизации.
Проблема состоит в том, что сбор и транспортировка всей информации туда-сюда — не слишком хорошая идея, поскольку сообщения, несущие эту информацию, могут перегрузить часть сети. Фактически следует избегать любого алгоритма, который требует передачи информации, собираемой со всей сети, на одну из ее машин для обработки с последующей раздачей результатов. Использовать следует только децентрализованные алгоритмы. Эти алгоритмы обычно обладают следующими свойствами, отличающими их от централизованных алгоритмов:
Первые три свойства поясняют то, о чем мы только что говорили. Последнее, вероятно, менее очевидно, но не менее важно. Любой алгоритм, начинающийся со слов: «Ровно в 12:00:00 все машины должны определить размер своих входных очередей», работать не будет, поскольку невозможно синхронизировать все часы на свете. Алгоритмы должны принимать во внимание отсутствие полной синхронизации таймеров. Чем больше система, тем большим будет и рассогласование. В одной локальной сети путем определенных усилий можно добиться, чтобы рассинхронизация всех часов не превышала нескольких миллисекунд, но сделать это в масштабе страны или множества стран? Вы, должно быть, шутите.
Другая проблема, препятствующая географическому масштабированию, состоит в том, что связь в глобальных сетях фактически всегда организуется от точки к точке и потому ненадежна. В противоположность глобальным, локальные сети обычно дают высоконадежную связь, основанную на широковещательной рассылке, что делает разработку распределенных систем для них значительно проще. Для примера рассмотрим проблему локализации службы. В локальней сети система просто рассылает сообщение всем машинам, опрашивая их на предмет предоставления нужной службы. Машины, предоставляющие службу, отвечают на это сообщение, указывая в ответном сообщении свои сетевые адреса. Невозможно представить себе подобную схему определения местоположения в глобальной сети. Вместо этого необходимо обеспечить специальные места для расположения служб, которые может потребоваться масштабировать на весь мир и обеспечить их мощностью для обслуживания миллионов пользователей.
Географическая масштабируемость жестко завязана на проблемы централизованных решений, которые мешают масштабированию по размеру. Если у нас имеется система с множеством централизованных компонентов, то понятно, что географическая масштабируемость будет ограничиваться проблемами производительности и надежности, связанными с глобальной связью. Кроме того, централизованные компоненты в настоящее время легко способны вызвать перегрузку сети. Представьте себе, что в каждой стране существует всего одно почтовое отделение. Это будет означать, что для того, чтобы отправить письма родственникам, вам необходимо отправиться на центральный почтамт, расположенный, возможно, в сотнях миль от вашего дома. Ясно, что это не тот путь, которым следует идти.
И, наконец, нелегкий и во многих случаях открытый вопрос, как обеспечить масштабирование распределенной системы на множество административно независимых областей. Основная проблема, которую нужно при этом решить, состоит в конфликтах правил, относящихся к использованию ресурсов (и плате за них), управлению и безопасности.
Так, множество компонентов распределенных систем, находящихся в одной области, обычно может быть доверено пользователям, работающим в этой области. В этом случае системный администратор может тестировать и сертифицировать приложения, используя специальные инструменты для проверки того факта, что эти компоненты не могут ничего натворить. Проще говоря, пользователи доверяют своему системному администратору. Однако это доверие не распространяется естественным образом за границы области.
Обсуждение некоторых проблем масштабирования приводит нас к вопросу о том, а как же обычно решаются эти проблемы. Поскольку проблемы масштабируемости в распределенных системах, такие как проблемы производительности, вызываются ограниченной мощностью серверов и сетей, существуют три основные технологии масштабирования: сокрытие времени ожидания связи, распределение и репликация.
Концептуально можно предположить даже, что все документы размещаются на одном сервере. Однако среда Web физически разнесена по множеству серверов, каждый из которых содержит некоторое количество документов. Имя сервера, содержащего конкретный документ, определяется по URL адресу документа. Только благодаря подобному распределению документов Всемирная паутина могла вырасти до ее современных размеров.
При рассмотрении проблем масштабирования, часто проявляющихся в виде падения производительности, нередко хорошей идеей является репликация (replication) компонентов распределенной системы. Репликация не только повышает доступность, но и помогает выровнять загрузку компонентов, что ведет к повышению производительности. Кроме того, в сильно географически рассредоточенных системах наличие близко лежащей копии позволяет снизить остроту большей части ранее обсуждавшихся проблем ожидания завершения связи.
Кэширование (caching) представляет собой особую форму репликации, причем различия между ними нередко малозаметны или вообще искусственны. Как и в случае репликации, результатом кэширования является создание копии ресурса, обычно в непосредственной близости от клиента, использующего этот ресурс. Однако в противоположность репликации кэширование — это действие, предпринимаемое потребителем ресурса, а не его владельцем.
Допустимая степень противоречивости зависит от степени загрузки ресурсов. Так, множество пользователей Web считают допустимым работу с кэшированным документом через несколько минут после его помещения в кэш без дополнительной проверки. Однако существует множество случаев, когда необходимо гарантировать строгую непротиворечивость, например, при игре на электронной бирже. Проблема строгой непротиворечивости состоит в том, что изменение в одной из копий должно немедленно распространяться на все остальные. Кроме того, если два изменения происходят одновременно, часто бывает необходимо, чтобы эти изменения вносились в одном и том же порядке во все копии. Для обработки ситуаций такого типа обычно требуется механизм глобальной синхронизации. К сожалению, реализовать масштабирование подобных механизмов крайне трудно, а может быть и невозможно. Это означает, что масштабирование путем репликации может включать в себя отдельные немасштабируемые решения.