По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Универсальный уникальный идентификатор (UUID - Universally Unique Identifier) – это форма идентификатора, которую можно с уверенностью признать уникальной для большинства практических целей. Даже если два UUID были сгенерированы в двух различных средах двумя сторонами, они имеют ничтожные шансы на то, чтобы оказаться идентичными. Именно поэтому UUID считаются универсально уникальными.
В этой статье мы с вами рассмотрим характеристики UUID, то, как работает их уникальность, и сценарии, для которых они могут упростить процесс идентификации ресурсов. Несмотря на то, что мы будем рассматривать UUID с точки зрения программного обеспечения, которое взаимодействует с записями базы данных, их также можно применять и в других ситуациях, где требуется децентрализованная генерация уникальных идентификаторов.
Что такое на самом деле универсальный уникальный идентификатор (UUID)?
UUID – это просто значение, которое с уверенностью можно рассматривать как уникальное. Вероятность обнаружения двух одинаковых UUID настолько мала, что ее можно просто игнорировать. Вы можете встретить и другие термины для UUID, например, GUID (Globally Unique Identifier, - глобальный уникальный идентификатор) (такой вариант предпочитает Microsoft), однако смысл и свойства остаются теми же.
Истинный UUID – это уникальный идентификатор, который был сгенерирован и представлен в стандартизированном формате. Допустимые UUID определены в спецификации RFC 4122. Она описывает алгоритмы, которые можно использовать для генерации UUID, которые бы сохраняли свою уникальность в различных реализациях без участия основной выдающей стороны.
В RFC есть пять различных алгоритмов. У каждого из этих алгоритмов есть свой собственный механизм генерации значений. Ниже приведено краткое описание доступных «версий»:
Версия 1 – Time-Based – объединяет метку времени, тактовую последовательность и значение, которое является характерным для генерирующего устройства (как правило, это MAC-адрес); таким образом создается выходное значение, которое является уникальным для этого хоста на определенный момент времени.
Версия 2 – DCE Security – эта версия была создана как модификация Версии 1, которую можно использовать в среде распределенных вычислений (DCE - Distributed Computing Environment). Применяется не так часто.
Версия 3 – Name-Based (MD5) – MD5 хеширует «пространство имен» и «имя» для того, чтобы создать значение, которое будет уникальным для этого имени в пределах пространства имен. Попытка создать другой UUID с тем же пространством имен и тем же именем приведет к тому, что вы получите идентичный результат. Так что, этот метод дает воспроизводимые результаты.
Версия 4 – Random – большинство современных систем выбирают именно эту версию, поскольку здесь для получения выходного значения используется источник случайных и псевдослучайных чисел. Вероятность того, что будут созданы два одинаковых UUID, ничтожна мала.
Версия 5 – Name-Based (SHA-1) – эта версия в какой-то степени похожа на Версию 3, но здесь для хеширования пространства имен и имени используется более криптостойкий алгоритм SHA-1.
Хоть в RFC алгоритмы и обозначены как «версии», это ни в коем случае не значит, что всегда нужно использовать Версию 5, потому что она вроде бы самая новая. Выбор версии зависит от вашего варианта использования; зачастую выбирается Версия 4 из-за случайного характера генерации значений. Именно это делает ее идеальным вариантом для простых сценариев из разряда «дайте мне новый идентификатор».
Алгоритмы генерации на выходе дают 128-битное целое число без знака. Но при этом UUID чаще всего рассматривают как шестнадцатеричные строки. Также их можно хранить в виде двоичной последовательности из 16 символов. Ниже приведен пример UUID:
16763be4-6022-406e-a950-fcd5018633ca
Значение записано с помощью пяти групп буквенно-числовых символов, разделенных дефисом. Последние не являются обязательными составляющими строки; их наличие связано с историческими тонкостями спецификации UUID. А еще они значительно облегчают зрительное восприятие идентификатора.
Варианты использования UUID
В основном UUID используют для децентрализованного создания уникальных идентификаторов. Вы можете создать UUID где угодно и с уверенностью сказать, то он уникальный, независимо от того, был он создан на вашем сервере, в клиентском приложении или в вашей базе данных.
UUID упрощают определение и обеспечение идентичности объекта в изолированных средах. Согласно сложившейся практике, большинство приложений в качестве первичного ключа используют целочисленное поле с автоинкрементом. В таком случае, когда вы создаете новый объект, то вы не узнаете его идентификатор до тех пор, пока не добавите его в базу данных. С помощью UUID вы можете определить идентификатор в вашем приложении намного раньше.
Ниже приведен демонстрационный пример, написанный на PHP, который покажет разницу. Для начала давайте посмотрим на целочисленную систему:
class BlogPost {
public function __construct(
public readonly ?int $Id,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost(null, $headline);
}
Мы должны инициализировать свойство
$Id
как
null
, поскольку мы не будем знать его фактический идентификатор до тех пор, пока не добавим его в базу данных. Это не самый идеальный вариант –
$Id
не должен обнуляться, из-за этого экземпляры
BlogPost
находятся в незавершенном состоянии.
Перейдем к UUID; это решит проблему:
class BlogPost {
public function __construct(
public readonly string $Uuid,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost("16763be4-...", $headline);
}
Идентификаторы публикаций теперь можно создавать прямо в приложении, не думая о том, что они могут повториться. Это гарантирует, что экземпляры объекта всегда находятся в действительном состоянии и что ну нужно присваивать ID нулевое значение. Также эта модель упрощает обработку транзакционной логики; дочерние записи, которым нужна ссылка на родителя (например, взаимосвязи автора (
Author
) нашей публикации), могут быть добавлены немедленно, и не нужно обращаться к базе данных для того, чтобы получить идентификатор родителя.
В перспективе большую часть логики данного приложения-блога можно будет переместить на клиентскую сторону. Возможно, внешний интерфейс сможет поддерживать полностью автономное создание черновиков, по сути создавая экземпляры
BlogPost
, которые будут временно сохраняться на устройстве пользователя. Теперь клиент может создавать UUID для публикации и, если ему нужно будет восстановить подключение к сети, передавать его на сервер. Если в обозримом будущем клиент получит копию черновика с сервера, то он сможет сравнить ее с любым сохранившимся локальным состоянием, так как он уже будет знать UUID.
С помощью UUID можно комбинировать данные из различных источников. Объединение таблиц базы данных и кэшей, которые используют целочисленные первичные ключи, может оказаться довольно трудоемким процессом, и, плюс ко всему, в процессе могут возникать ошибки. UUID обеспечивает уникальность идентификатора не только внутри таблиц, но и на уровне всего пространства. Это делает их более предпочтительным вариантом для дублируемых структур и данных, которые часто необходимо перемещать из одной системы хранения в другую.
Нюансы, возникающие при встрече UUID с базами данных
Преимущества UUID довольно привлекательны. Однако есть несколько подводных камней, о которых следует помнить при использовании UUID в реальных системах. Один из значительных факторов в пользу целочисленных идентификаторов – их легко масштабировать и оптимизировать. Механизмы управления базами данных могут с легкостью индексировать, сортировать и фильтровать список чисел, которые идут одно за другим.
А вот про UUID такого сказать нельзя. Прежде всего, UUID в четыре раза больше, чем целое число (36 против 4 байтов); для больших наборов данных этот факт уже может быть существенным моментом. Такие значения намного сложнее сортировать и индексировать, особенно если речь идет о случайных UUID, которые являются самыми популярными. Их случайный характер говорит о том, что они не имеют естественного порядка. Если вы используете UUID в качестве первичного ключа, то это может навредить производительности при индексировании.
Все эти проблемы могут усугубляться в хорошо нормализованной базе данных, которая активно использует внешние ключи. В таком случае у вас может оказаться большое количество реляционных таблиц, каждая из которых хранит ссылки на ваши 36-байтные UUID. В конечном счете, дополнительная память, которая необходима для выполнения операций объединения и сортировки, может негативно сказаться на производительность вашей системы.
У вас есть возможность немного сгладить нежелательные последствия, сохранив свои UUID в виде двоичных данных. Это значит, что вместо столбца
VARCHAR(36)
у вас будет столбец
BINARY(16)
. Некоторые базы данные, например, PostgreSQL, имеют встроенный тип данных
UUID
; другие, например, MySQL, имеют специальные функции, которые преобразовывают строку UUID в двоичную форму и наоборот. Такой подход, конечно, более эффективный, но не забывайте, что вам по-прежнему придется использовать дополнительные ресурсы для хранения и выборки данных.
Эффективной может оказаться стратегия, когда вы в качестве первичных ключей оставляете целые числа, но при этом добавляете дополнительное поле UUID для того, чтобы ваше приложение могло на него ссылаться. Реляционные таблицы ссылок могут использовать идентификаторы для повышения производительности, пока ваш код извлекает и вставляет объекты верхнего уровня с UUID. Здесь все зависит от вашей системы, ее масштаба и ваших приоритетов: если вам нужна децентрализованная генерация идентификаторов и простейшее слияние данных, то лучший вариант – это UUID, но вам следует помнить и об обратной стороне медали.
Заключение
UUID – это уникальные значения, которые можно использовать для децентрализованной генерации идентификаторов. Совпадение идентификаторов возможно, но вероятность такого события настолько мала, что ее можно не учитывать. Если бы вы генерировали один миллиард UUID в секунду в течении 100 лет, то вероятность обнаружить дубликат составила бы около 50% при условии наличия достаточной энтропии.
У вас есть возможность использовать UUID для установления идентичности независимо от вашей базы данных до того, как вы добавите объект в базу данных. Такой подход упрощает код прикладного уровня и не допускает того, что объекты в вашей системе будут идентифицированы неправильно. UUID также содействуют репликации данных, гарантируя уникальность вне зависимости от хранилища данных, устройства или среды, чего нельзя сказать о целочисленных ключах, которые действуют на уровне таблиц.
Несмотря на то, что UUID широко используются при разработке программного обеспечения, они не являются идеальным решением. Новички часто зацикливаются на возможности обнаружения совпадений, но это не должно быть вашим главным аргументом, если только ваша система не настолько чувствительна, что вам просто необходимо гарантировать уникальность идентификаторов.
Более очевидная проблема для большинства разработчиков заключается в хранении и извлечении сгенерированных UUID. Примитивное использование
VARCHAR(36)
(или
VARCHAR(32)
, если вы удалите дефисы) в долгосрочной перспективе может оказывать негативное влияние на ваше приложение, так как большая часть попыток оптимизировать индексацию базы данных будут неэффективными. Изучите встроенные средства обработки UUID в вашей системе управления базой данных для того, чтобы максимально улучшить производительность вашего программного решения.
Телефонная станция Cisco Unified Communications Manager (далее CUCM) является системой обработки вызовов на базе программного обеспечения, разработанного компанией Cisco Systems. Первая версия CUCM была анонсирована в 1997 году, под названием CallManager 1.0. На момент написания статьи последняя и самая актуальная версия - CUCM 10.5. CUCM работает с такими элементами сетей передачи голоса поверх протокола IP (VoIP) как: шлюзы, телефонные аппараты, мосты для конференцсвязи, голосовая почта, видеоконференцсвязью и многими другими.
Чаще всего, для работы с оконечными устройствами CUCM использует собственный протокол сигнализации, разработанный компанией Cisco Systems под названием Skinny Client Control Protocol (SCCP). Помимо собственных разработок, CUCM поддерживает и открытые стандарты, такие как H.323, Media Gateway Control Protocol (MGCP) или Session Initiation Protocol (SIP). Схема работы CUCM приведена рисунке ниже:
На рисунке схематично обозначена схема работы CUCM в рамках корпоративной сети. Пунктирными линиями обозначены Real-time Transport Protocol (RTP) потоки, которые переносят в поле информационной (полезной) нагрузки медиа – данные разговора. Особое внимание следует обратить на расположение линий направления RTP – они проходят напрямую от телефонного аппарата до телефонного аппарата. Телефонная станция CUCM контролирует телефонную сигнализацию, на данном примере, по протоколам SIP/SCCP. Это означает, что если во время разговора CUCM перестанет работать, разговор между абонентами будет продолжен, но такие функции как удержание, трансфер, отбой вызова и другие функции управления вызовом будут не доступны.
Цифровая телефонная станция CUCM выполнена на базе операционной системы Linux с закрытыми правами администратора и с предустановленной базой данных IBM Informix. В совокупности, такой вид операционной системы носит название VOS (voice operating system). Продукт устанавливается пакетом, сначала VOS, а затем само программное обеспечение.
Интерфейс управления цифровой телефонной станцией CUCM выполнен как WEB – приложение, доступное через протокол HyperText Transfer Protocol (HTTP). Интерфейс имеет удобную навигацию по вкладкам, пять разных Graphical user interface (GUI) для сегментации функций администрирования и возможность предоставлять уровни доступа администраторам. Основной интерфейс проиллюстрирован на рисунке:
Как было сказано ранее, CUCM имеет пять различных панелей администрирования:
Cisco Unified CM Administration
Cisco Unified Reporting
Disaster Recovery System
Cisco Unified Serviceability
Cisco Unified OS Administration
Интерфейс Cisco Unified CM Administration – основной интерфейс администратора. Здесь можно настраивать системные настройки, параметры маршрутизации вызовов, настройка медиа – ресурсов, таких как Music On Hold (MOH), параметров интеграции с другими продуктами компании Cisco Systems, конфигурацию телефонных аппаратов, шлюзов, «привратников» (gatekeepers), администрирование групп пользователей и многие другие настройки.
Интерфейс Cisco Unified Reporting обеспечивает доступ к отчетам о работе телефонной станции. Данная консоль отчетности собирает данные с различных системных журналов и предоставляет эту информацию в просто для администратора виде.
Интерфейс Disaster Recovery System (DRS) создан для резервирования конфигурации, или как принято говорить «бэкапа» телефонной станции CUCM. Бэкап может происходить как локально на сервер, так и на удаленные площадки по протоколу SSH File Transfer Protocol (SFTP).
Графический интерфейс Cisco Unified Serviceability предоставляет наблюдение и контроль работоспособности телефонной станции, включая в себя такие настройки как конфигурацию опций оповещения о проблемах в работе CUCM, систему трассировки для обнаружения причин проблем, богатое меню инструментов, в котором можно смотреть отчеты Call Detail Record (CDR). Данный интерфейс позволяет настроить параметры Simple Network Management Protocol (SNMP), созданного для управления и контроля.
Последним в списке интерфейсов значится Cisco Unified OS Administration. Он предназначен для мониторинга аппаратной платформы и различных системных статистических данных, таких как: загруженность центрального процессора, свободного пространства жестких дисков, мониторинга системного времени, информации об IP – адресах, работы в рамках протокола Internet Control Message Protocol (ICMP).
Еще один немаловажный интерфейс, это Command Line Interface (CLI) – консоль. Он удобен для перезагрузки сервиса, например, при недоступности основного графического интерфейса через порт 8080.
Cisco UCM - решение для крупного бизнеса или государственного учреждения
Телефонная станция CUCM это гибкое и масштабируемое решение. Одним из важных преимуществ является возможность кластеризации серверов, или другими словами объединения. В общем случае, в одном кластере может работать до 20 серверов. Среди них только 8 серверов занимаются обработкой вызовов, остальные, это дополнительные сервера предназначенные для расширения функционала кластера (сервисы музыка на удержании, Trivial File Transfer Protocol (TFTP) сервер и многие другие). Работая в кластере, сервера CUCM могут работать с 30 000 абонентами.
При работе в кластере различают два типа серверов – «паблишер» (публикатор) и «сабскрайбер» (подписчики). В данной модели один сервер, который является «паблишером» дублирует базу данных на все остальные сервера, которые являются «сабскрайберами. Схема работы кластера показана на рисунке:
Большое преимущество IP PBX CUCM – это возможность развернуть сервер в виртуальной среде.
Системы виртуализации появились после того, как соотношение эффективности использования одного аппаратного сервера к стоимости данного сервера, с каждым днем стремилось к меньшему и меньшему значению. Виртуализация позволяет делить аппаратные ресурсы сервера между различными приложениями. Например, предприятие покупает аппаратный сервер, для конкретной цели. Системный администратор данной организации устанавливает на него операционную систему на базе Windows, а затем, приложение, для которого был куплен этот сервер. Спустя некоторое время, у организации появилось требование для внедрения в корпоративный контур бизнес – приложений, которые работают на базе Linux. За неимением систем виртуализации, компания сталкивается с новой проблемой – покупкой нового сервера, по причине того, что разнородные операционные системы не смогут существовать на одном и том же аппаратном ресурсе.
При наличии системы виртуализации, компания может установить специальное программное обеспечение «гипервизор» на имеющийся Windows сервер. Гипервизор позволит изолировать друг от друга различные операционные системы на одном и том же сервере, обеспечит безопасность, защиту, целостность данных, предоставит централизованное и удобное управление виртуальным серверным ресурсом компании, а так же множество встроенных средств и инструментов автоматизации, предназначенных для автоматического резервирования данных и конфигурации серверов. Предприятия решит поставленную задачу, оптимизировав расходы на аппаратные сервера.
Преимущества
Выделим основные конкурентные преимущества систем виртуализации
Экономия расходов предприятия на покупке дополнительного сервера.
Экономия места в телекоммуникационной стойке.
Снижение тепловыделения и электропотребления.
«Бесшовное» обновление операционной системы сервера, позволяющее не производить перезагрузку и не останавливать работу приложения.
Централизация управления и администрирования серверов.
Гибкая настройка конфигурации, автоматического резервирования. Создание отказоустойчивости внутренними средствами программного обеспечения гипервизора.
Общий принцип работы систем виртуализации проиллюстрирован на рисунке: Виртуализация CUCM
Ведущие производители систем виртуализации, это такие компании как VMware, Hyper-V, Xen и Citrix Systems.
В небольших сетевых устройствах с одним сетевым процессом (ASIC или NPU) переместить пакет из входной очереди в выходную просто. Оба интерфейса ввода и вывода используют общий пул памяти пакетов, поэтому указатель на пакет может быть перемещен из одной очереди в другую.
Для достижения большего количества портов и более крупных устройств - особенно устройств шасси - должна быть внутренняя шина или матрица, которая соединяет механизмы обработки входных и выходных пакетов. Одним из распространенных типов структуры, используемой для соединения механизмов обработки пакетов в сетевом устройстве, является структура матрицы; Рисунок ниже иллюстрирует это.
Размер и структура полотна матрицы зависят от количества подключенных портов. Если в коммутаторе больше портов, чем возможно для подключения через одну матрицу кросс-панелей, то коммутатор будет использовать несколько структур кросс-панелей. Распространенной топологией для такого типа полотна является многоступенчатая закрытая структура, соединяющая входную и выходную полотна матрицы вместе. Вы можете думать об этом как о матрице из матриц.
Для работы матрицы требуется чувство времени (или, скорее, фиксированный временной интервал) и планировщик. В каждый интервал времени один порт вывода (отправки) соединяется с одним портом ввода (приема), так что в течение этого периода времени отправитель может передать пакет, кадр или набор пакетов получателю. Планировщик "соединяет" правильные точки пересечения на матрице, чтобы передачи происходили в нужный период времени. Например:
Line card 1 (LC1) хочет отправить пакет в LC3.
LC3 хочет отправить пакет в LC5.
В течение следующего временного цикла планировщик может подключить строку A к столбцу 1 ("установить" соединение в A3) и подключить строку C к столбцу 5 ("установить" соединение в C5), чтобы между этими парами был установлен канал связи.
Пересечения и конфликты
Что произойдет, если два передатчика захотят отправить пакет одному получателю? Например, если в течение одного периода времени и LC1, и LC2 хотят отправить пакет в LC9 через полотно перекрестной матрицы? Это называется конфликтом, и это ситуация, которую должен обрабатывать планировщик структуры. Какому из двух входных портов должно быть разрешено отправлять свой трафик на выходной порт? А где же тем временем должны находится очереди входящего трафика?
Один из вариантов - хранить пакеты во входной очереди; коммутаторы, использующие эту технику, называются коммутаторами с очередью ввода (input-queued switches). Такие коммутаторы испытывают head-of-line (HOL). Блокировка HOL - это то, что происходит, когда пакет в начале линии, ожидающий пересылки через структуру, блокирует другие пакеты, стоящие в очереди за ним.
Другой вариант - использовать в коммутаторе несколько виртуальных очередей вывода (virtual output queues- VOQ) для каждого порта ввода.
VOQ дают матрице перекрестной сети несколько мест для хранения входящих пакетов, пока они ожидают доставки на свои выходные порты. Во многих конструкциях коммутаторов один VOQ существует на каждый выходной порт, для которого предназначен входной трафик. Следовательно, входной порт может иметь несколько пакетов в очереди в нескольких разных VOQ, предполагая, что несколько разных выходных портов.
Каждый из этих VOQ может обслуживаться в течение одного тактового цикла. Это означает, что блокировка HOL устраняется, потому что несколько разных пакетов из одной входной очереди могут проходить через матрицу кроссбара одновременно. Для порта ввода существует не одна очередь, а несколько разных очередей.
Даже с VOQ остается потенциальная возможность разногласий по структуре перекрестной сети. Наиболее распространенный пример - это когда два или более входящих пакета должны покинуть коммутатор через один и тот же выходной порт в одно и то же время, или, точнее, в одном тактовом цикле. Выходной порт может отправлять только один пакет за такт.
Определение того, какая входная очередь будет доставлять трафик на выходной порт первой, - это алгоритм, определяемый производителем коммутатора для максимального использования аппаратного обеспечения. iSLIP-это один из алгоритмов планирования, используемых коммутаторами для решения этой проблемы.
Обзор алгоритма iSLIP
Алгоритм iSLIP разрешает конфликты межсетевых экранов, распределяя трафик таким образом, чтобы сетевое устройство достигало неблокирующей пропускной способности. Для понимания этого полезно внимательно изучить iSLIP в его простейшей форме, проанализировав, что происходит, когда алгоритм iSLIP выполняется один раз.
Во время выполнения iSLIP происходят три важных события:
Запрос. Все входные точки (вход) на перекрестной матрице с поставленным в очередь трафиком спрашивают свои выходные точки (выход), могут ли они отправить.
Предоставление (грант). Каждая точка вывода, получившая запрос, должна определять, какая точка ввода будет разрешена для отправки. Если есть один запрос, то грант предоставляется без дальнейшего обсуждения. Однако при наличии нескольких запросов точка вывода должна определять, какая точка ввода может отправлять. Это делается через циклического перебора, где одному запросу предоставляется грант, последующему запросу предоставляется грант во время следующего выполнения iSLIP, и так далее по кругу. Когда было принято решение об этом конкретном выполнении iSLIP, каждая точка вывода отправляет свое сообщение о предоставлении, эффективно сигнализируя о разрешении на отправку, в соответствующую точку ввода.
Принятие. Входная точка рассматривает сообщения о предоставлении гранта, полученные ею от выходных точек, выбирая грант циклическим способом. После выбора входной сигнал уведомляет выходной сигнал о том, что грант принят. Если и только, если выходная точка уведомлена о том, что грант был принят, выходная точка перейдет к следующему запросу. Если сообщение accept не получено, то точка вывода попытается обслужить предыдущий запрос во время следующего выполнения iSLIP.
Понимание процессов запроса, предоставления и принятия дает нам представление о том, как пакеты могут быть доставлены одновременно через матрицу кроссбара без конфликтов. Однако, если вы поразмыслите над сложным набором входов, VOQ и выходов, вы можете понять, что один запуск iSLIP не планирует доставки столько пакетов, сколько могло бы быть после одного выполнения.
Понимание процессов запроса, предоставления и принятия дает нам представление о том, как пакеты могут быть доставлены одновременно через матрицу кроссбара без конфликтов. Однако, если вы поразмыслите над сложным набором входов, VOQ и выходов, вы поймете, что один запуск iSLIP не планирует доставки столько пакетов, сколько могло бы быть после одного выполнения.
Конечно, некоторые входы были предоставлены выходам, и некоторые пакеты могут быть переадресованы, но возможно, что некоторые выходы никогда не были согласованы с ожидающим входом. Другими словами, если вы ограничите iSLIP одним исполнением за такт, мы оставим доступную выходную полосу пропускания неиспользуемой.
Поэтому обычной практикой является запуск iSLIP через несколько итераций. В результате количество совпадений ввода-вывода максимально. За один раз через матрицу кроссбара может быть отправлено больше пакетов. Сколько раз нужно запускать iSLIP, чтобы максимально увеличить количество пакетов, которые можно коммутировать через матрицу кроссбара за такт? Исследования показывают, что для шаблонов трафика, преобладающих в большинстве сетей, запуск iSLIP четыре раза лучше всего сопоставляет входные и выходные данные в матрице. Выполнение iSLIP более четырех раз не приводит к значительному увеличению количества совпадений. Другими словами, запуск iSLIP пять, шесть или десять раз в большинстве сетевых сред ничего не даст.
Выход за рамки iSLIP
Это обсуждение до сих пор предполагало, что движение, протекающее через матрицу, имеет одинаковое значение. Однако в современных центрах обработки данных одни классы трафика имеют приоритет над другими. Например, фреймы хранилища Fibre Channel over Ethernet (FCoE) должны проходить через матрицу без потерь, в то время как сеанс TCP, попадающий в класс QoS, этого не делает.
Обрабатывает ли iSLIP трафик с разными приоритетами, отдавая одни запросы раньше других? Да, но в модифицированной форме алгоритма, который мы рассмотрели. Варианты iSLIP включают Приоритетный, Пороговый и Взвешенный iSLIP.
Помимо iSLIP, который здесь используется просто как удобный пример управления конфликтами, поставщики будут писать свои собственные алгоритмы, соответствующие аппаратным возможностям своей собственной коммутационной матрицы. Например, в этом разделе рассматривается только матрица перекрестных линий с входящей очередью, но многие структуры перекрестных линий предлагают также организацию очереди вывода на выходной стороне матрицы.