Мой сайт
Главная
Вход
Регистрация
Воскресенье, 22.10.2017, 14:53Приветствую Вас Гость | RSS
Меню сайта

Наш опрос
Оцените мой сайт
Всего ответов: 4

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Форма входа

Главная » 2013 » Июль » 16 » ЦОД. Часть 5. О жизни VM в центрах обработки данных
06:13
 

ЦОД. Часть 5. О жизни VM в центрах обработки данных

ЦОД. Часть 5. О жизни VM в центрах обработки данных

Когда виртуальные машины (VМ) «живут» в пределах единственного ЦОД – это одна история. Конечно, и в ней присутствуют свои нюансы, которые могут испортить настроение системным и сетевым администраторам, но о них, возможно, поговорим в следующей части блога о ЦОД. И совсем другая история, когда организация использует несколько ЦОД, и VМ могут или должны перемещаться между ними.

Сразу, конечно, следует уточнить, что будем понимать под термином «перемещение» VМ? В самом общем случае – два сценария.

Один их них, когда имеется возможность «выключить» VМ в одном ЦОД, затем выполнить, если этого не было сделано заранее, подготовительные операции, связанные с переносом набора данных, соответствующей этой VМ, в другой ЦОД, и «включить» VМ на другом физическом сервере, то есть осуществить ее инициализацию с присвоением, чаще всего, другого IP-адреса. В чем важно удостовериться после инициализации VМ в другом ЦОД? Следует убедиться, что в сервере разрешения имен, отвечающем за данный домен, – DNS-сервере – внесено изменение, касающееся IP-адреса приложения, по которому оно теперь доступно.

Очевидно, что такой сценарий означает перерыв в функционировании VМ и, следовательно, приложения. Какова может быть длительность этого перерыва? Она зависит от нескольких факторов – размера соответствующего данной VМ файла (VМ-файла), который включает компоненты гостевой операционной системы и используемого приложения; размера набора данных, с которым работает приложение; пропускной способности сегментов сети между ЦОД. Полагая, что размер VМ-файла (например, .vmdk или .qcow) может достигать нескольких гигабайт или даже нескольких десятков гигабайт, набор данных имеет примерно такой же объем, и один из сегментов сети с производительностью 1 Gbps полностью монополизирован задачей перемещения VМ между ЦОД (а также грубо полагая, что издержки – заголовки кадров уровней L2, L3, L4, межкадровые интервалы, сигнальные сообщения протокола передачи – составляют 20%, другими словами, производительность данного сегмента сети оценивается примерно в 100MBps), неработоспособность данного приложения может составлять от нескольких минут до нескольких десятков минут. Очевидно, что именно это значение имеют в виду, когда оценивают является ли приемлемым такой перерыв в предоставлении сервиса приложением.

Однако есть еще один фактор, который оказывается в состоянии повлиять на длительность перерыва в предоставлении сервиса приложением и который, как правило, выпадает из внимания, поскольку непосредственно не связан с операциями перемещения VМ между ЦОД. И этим фактором является «время жизни» в кэше результата DNS-запроса на разрешение имени приложения. Проблема состоит в том, что для направления запроса к приложению используется ранее сохраненный в кэше IP-адрес приложения, которое в рассматриваемом сценарии при перемещении в другой ЦОД получает новый IP-адрес. Таким образом, запрос направляется на IP-адрес, которого уже не существует, и, следовательно, такой запрос не может быть обслужен. Если пользователь приложения является сотрудником вашей организации, то результат DNS-запроса обычно кэшируется либо операционной системой рабочей станции пользователя, либо клиентской частью приложения. Время, в течение которого результат DNS-запроса сохраняется в кэше, например, операционной системы Windows составляет по умолчанию 30 мин. Если пользователь приложения не является сотрудником вашей организации и получает доступ к вашему приложению, например, посредством сети Internet, то в этом случае определяющее значение имеет политика, принятая оператором (-ми) в отношении длительности хранения результатов DNS-запросов на DNS-сервере – обычно она составляет 24 часа. Соответственно, для такого пользователя перерыв в предоставлении сервиса приложением после перемещения связанной с ним VМ в другой ЦОД может составлять сутки.

Таким образом, длительность перерыва в предоставлении сервиса приложением в рамках рассматриваемого сценария определяется наибольшим их двух значений – длительностью выполнения операций по инициализации VМ в другом ЦОД и «временем жизни» в кэше результата DNS-запроса на разрешение имени приложения.

И если требования к ведению бизнес-операций допускают такой перерыв, то применение данного, «холодного», сценария для миграции VМ в другой ЦОД является, на мой взгляд, предпочтительным. Почему? Да потому что он является наиболее простым.

Второй, «горячий» (Live Move), сценарий перемещения VМ между ЦОД предназначен для тех случаев, когда не допускается прерывания выполнения операций. Разумеется, в этом случае необходимым условием является сохранение VМ своего IP-адреса и после перемещения в другой ЦОД. Очевидно, добиться этого возможно, «растянув» VLAN (L2-сегмент) и соответствующую IP-подсеть между несколькими ЦОД, то есть, решив задачу, которая обозначается термином L2 Extension.

Что может быть сложного в такой задаче? Между коммутатором, а точнее парой коммутаторов, уровня L2 одного ЦОД и парой коммутаторов уровня L2 другого ЦОД организуется, как правило, два L2-сегмента, способные поддерживать передачу кадров в формате протоколов IEEE 802.1Q и/или IEEE 802.1ad, как показано на рис. 1.




Рис. 1

Решение простое – куда еще проще? Но за эту простоту приходиться платить. Чем? А тем, что в результате образуется один, общий для нескольких ЦОД, STP-домен. И последствия этого таковы.

Во-первых, в силу спецификации протокола STP, в рамках одной и той же VLAN из всех возможных путей между ЦОД, активным будет только один (см. рис. 1), а все остальные окажутся блокированными. Между прочим, это означает еще и то, что этот единственный активный путь не может быть использован только лишь для операций, направленных на поддержку миграции VM, а значит, при таких обстоятельствах и время миграции удлиняется.

В-вторых, изменение состояния портов коммутаторов, входящих в STP-домен, или каналов связи между ними влечет сначала появление сообщений TCN (Topology Change Notification), (которые, кстати, являются широковещательными и, следовательно, распространяются по всему STP-домену), а затем и пересчет коммутаторами L2-топологии – и до тех пор, пока этот процесс не завершился, все кадры данных передаются в режиме широковещательной рассылки, что приводит к кратковременным широковещательным штормам, накрывающим несколько ЦОД. Кстати, даже стабильное функционирование STP-домена сопровождается широковещательными рассылками кадров (например, ARP-запросы), которые распространяются по нескольким ЦОД, что ко всему прочему снижает полезную производительность физических серверов.

И, наконец, в-третьих, стабильное поведение STP-домена является потенциально весьма неустойчивым к воздействию человеческого фактора, то есть, к ошибкам, которые могут быть допущены – и нередко допускаются – даже подготовленными администраторами. Речь, например, идет о том, что даже такая операция, как добавление в VLAN коммутатора может повлечь нежелательное изменение L2-топологии из-за того, что этот коммутатор может принять на себя роль Root Bridge, если администратор заранее не позаботится о том, чтобы этого не произошло.

Очевидно, решение задачи L2 Extension, что называется, «в лоб», описанным выше способом, является крайней мерой. И перед ее осуществлением следует семь раз подумать о том воздействии на непрерывность соединений, а значит и операций, возможность которых предоставляется в рамках «горячего» сценария перемещения VM между ЦОД, которое может оказать нестабильное поведение STP-домена, вероятность чего тем выше, чем больше размер STP-домена.

Какие еще способы – и, скорее всего, интерес представляют не все, а только те из них, которые видятся релевантными – могут быть предложены для решения задачи L2 extension? Сначала проясним, что вкладывается в понятие релевантности. Например, для решения задачи L2 Extension могут быть использованы технологии VPLS, A-VPLS, BGP MPLS-based MAC VPN. Однако, по-видимому, мало у каких организаций в стране в качестве транспортной инфраструктуры используются сети на базе технологии MPLS, и, следовательно, упомянутые выше технологии вряд ли представляют практический интерес. Кроме того, релевантными будем считать такие способы, которые, во-первых, обеспечивают множественность активных путей между ЦОД, и, во-вторых, изолируют STP-домены ЦОД друг от друга. И все же, что это за способы? Я бы назвал следующие – M-LAG, TRILL/SPB, OTV.

Если ЦОД отстоят друг от друга на несколько десятков километров, что на практике чаще всего и наблюдается в стране (как правило, в этом случае в качестве транспортной инфраструктуры используются ВОЛС), то самым простым и, очевидно, дешевым является применение технологии M-LAG (MultiChassis Link Aggregation Group). M-LAG позволяет отказаться от применения протокола STP при построении участка сети между ЦОД, как следствие, все доступные между ЦОД каналы связи могут быть использованы для транспортировки данных в рамках одной и той же VLAN, как проиллюстрировано на рис. 2.




Рис. 2




Однако, следует иметь в виду, что такой участок сети между ЦОД остается, тем не менее, прозрачным для кадров BPDU, инициируемых в STP-доменах в ЦОД. Поэтому для того чтобы изолировать STP-домены в ЦОД друг от друга, на пограничных коммутаторах в ЦОД необходимо включить фильтры, блокирующие распространение таких кадров BPDU.

О чем еще нужно помнить о технологии M-LAG перед тем, как принять решение о ее применении? Стандарта, описывающего спецификацию M-LAG, не существует. Другими словами, у каждого производителя коммутаторов имеется своя реализация M-LAG, а у иных производителей – даже несколько. Поэтому применение M-LAG, в некоторой степени, означает «привязку» к определенному производителю.

Если «привязка» к производителю является неприемлемой, то для организации участка сети между ЦОД вместо M-LAG могут быть использованы протоколы TRILL (Transparent Interconnection of Lots of Links), спецификация которого описана в RFC 6325, или протокол SPBM (Shortest Path Bridging - MAC), являющийся стандартом IEEE 802.1aq.

С точки зрения организации участка сети между ЦОД оба обладают примерно одинаковым потенциалом – в обоих случаях обеспечивается возможность использовать несколько путей между ЦОД для передачи трафика в рамках той же самой VLAN (различие состоит в количестве таких путей и в трудоемкости настройки), и в обоих случаях для изоляции STP-доменов ЦОД друг от друга, также как с M-LAG, требуется применять фильтры, блокирующие распространение кадров BPDU.

Следует заметить, что поскольку спецификация TRILL определяет новый формат кадра Ethernet, то это влечет применение новых микросхем и, следовательно, новых коммутаторов. Протокол SPBM может поддерживаться существующими коммутаторами после замены их программного обеспечения. И еще. Забавно, что хотя TRILL описывается спецификацией RFC 6325, но ни один из производителей, которые декларировали поддержку данного протокола, не реализовали его в точном соответствии с ней – пока на рынке присутствуют только частные версии этого протокола (у Cisco – Fabric Path, у Brocade – VCS Fabric).

Я не слышал о том (может быть, кто-то поделиться информацией в комментариях), чтобы ЦОД, принадлежащие какой-либо организации в стране, располагались на таком удалении друг от друга, которое исключало бы использование прямых ВОЛС. Тем не менее, в тех случаях, когда для организации соединений между ЦОД не удается использовать протоколы L2, и, следовательно, остается только вариант применения сети IP, можно рассмотреть применение следующих подходов.

Теоретически в таком случае для решения задачи L2 Extension между ЦОД можно использовать давно известный инструмент – туннели L2TPv3. Однако при наличии между ЦОД нескольких туннелей L2TPv3 для исключения образования петель требуется использовать протокол STP, который блокирует все, кроме одного, пути передачи данных в рамках VLAN.

Очевидно, что и изолировать STP-домены соседних ЦОД не представляется возможным, поскольку в случае блокировки кадров BPDU другого STP-домена теряется способность обнаруживать выход из строя одного из туннелей L2TPv3 и, следовательно, переключаться на резервный. А на это, как говорил герой известного шедевра советского кино, мы пойти не можем. Иными словами, использование туннелей L2TPv3 для решения задачи L2 Extension можно назвать «последним средством спасения», когда никаких других уже не осталось.

Другим способом для «растягивания» L2-сегмента через сеть IP является применение технологии OTV (Overlay Transport Virtualization). Что же в ней замечательного? Во-первых, OTV позволяет использовать одновременно несколько путей между ЦОД для передачи данных в рамках VLAN. Естественно, это возможно благодаря тому, что для построения топологии уровня L2 участка сети между ЦОД вместо протокола STP используется принципиально иной подход, Сначала посредством одного из протоколов динамической маршрутизации, например OSPF, строится топология L3 участка сети между ЦОД, затем с помощью протокола ECMP выбирается несколько L3-маршрутов. Для «растягивания» L2-сегмента применяется инкапсуляция кадра Ethernet а пакет IP, который продвигается по одному из ранее найденных путей. Вместо традиционного для L2-сетей изучения MAC-адресов серверов в соседних ЦОД посредством механизма широковещательного распространения кадров для построения таблицы коммутации применяется протокол IS-IS, с помощью которого происходит обмен сведениями между пограничными коммутаторами ЦОД о MAC-адресах серверов, расположенных в соседних ЦОД. Во-вторых, OTV имеет встроенный механизм блокировки широковещательных кадров уровня L2, в том числе кадров BPDU протокола STP, что автоматически обеспечивает изоляцию STP-доменов в ЦОД. Я бы назвал OTV почти «идеальной» технологией для решения задачи L2 Extension между ЦОД. Почему же почти? Дело в том, что она имеет «встроенное» ограничение в части масштабируемости – поскольку для каждой VLAN создается отдельный процесс IS-IS, то при изрядном количестве VLAN, которые должны присутствовать на всех ЦОД, могут возникнуть проблемы производительности. Однако вследствие масштабов наших организаций такое ограничение следует признать скорее чисто умозрительным. Гораздо более важным представляется другой фактор. Для этой технологии до настоящего времени не существует стандарта (скажем, RFC). Более того, ее развивает и, соответственно, поддерживает, насколько мне известно, только одна компания – Cisco. На мой взгляд, в нынешних условиях этого мало, слишком мало, даже если речь идет о Cisco. Тем не менее, конечно же, не уважать эту разработку Cisco просто нельзя. Для тех, кто решится применить OTV на практике, добавлю только, что ее поддержка реализована исключительно в коммутаторах серии Nexus 7000. Может быть, меня кто-нибудь поправит, но, насколько я помню, для этого требуется использовать еще и специализированные модули – модули M-серии.

Ну и одно общее замечание, касающееся применения технологий для «растягивания» L2-сегмента через сеть IP – L2TPv3 и OTV. Поскольку, скорее всего, в этом случае придется воспользоваться услугами IP-транспорта, предоставляемыми операторами, и поскольку для поддержки «горячего» сценария перемещения VM пропускная способность соединений между ЦОД, по крайней мере, в соответствии с рекомендациями VMware, должна быть не менее 622 Mbps, стоимость такого сервиса может быть весьма недешевой. Этот аспект нужно учитывать, планируя максимальное расстояние, на котором должны находиться друг от друга ЦОД.

Хорошо, предположим, задача L2 Extension решена с помощью той или иной из упомянутых выше технологий, и теперь VM имеет возможность перемещаться из одного ЦОД в другой без прерывания установленных соединений. При этом VM, естественно, продолжает работать с томом данных в исходном ЦОД. Однако вполне можно представить сценарий, когда для VM следует обеспечить возможность использовать локальное хранилище данных, находящееся в том ЦОД, куда она «переехала». Как это сделать? Возможным подходом является применение контроллера виртуализации СХД – SVC (Storage Virtualization Controller), в задачу которого входит, во-первых, создание и поддержание зеркального тома данных, и, во-вторых, при определенных условиях переключение «на лету» запросов VM с основного тома на зеркальный. Идея применения контроллера SVC проиллюстрирована на рис. 3.




Рис. 3




Между прочим, применение контроллера SVC имеет некоторые полезные побочные эффекты:

• исходя из своего назначения контроллер SVC отделяет логическую сущность СХД от ее физической, предоставляя тем самым возможность использовать в ЦОД СХД от разных производителей;

• контроллер SVC может выступать в качестве шлюза протоколов доступа к СХД – FC, FCoE, iSCSI; другими словами, предоставляется возможность осуществить постепенную, то есть с той скоростью, которая приемлема для самой организации, перехода от СХД с интерфейсами FC к СХД с интерфейсами iSCSI.

Теперь несколько отвлечемся от тех задач, которые было совершенно необходимо решить для обеспечения непрерывности ведения операций в случае «горячего» сценария перемещения VM между ЦОД, и посмотрим на миграцию VM глазами самого важного участника процесса – а именно, пользователя. Если до появления VM с их способностью перемещаться между ЦОД IP-адрес физического сервера фактически однозначно ассоциировался с его местонахождением, то теперь ситуация выглядит по-другому – VM с одним и тем же IP-адресом может находиться в любом из ЦОД. Возникает вопрос, в какой же из ЦОД следует отправлять запрос на обслуживание пользователя данной VM, или конкретным приложением? Вообще говоря, если запрос пользователя будет отправлен в тот ЦОД, в котором VM находилась до перемещения, то он все равно будет обслужен – ведь не зря же VLAN (или, по-другому, IP-подсеть) «растянули» между ЦОД. Но путь потока данных в этом случае будет явно неоптимальным – сначала запрос поступит в исходный ЦОД; затем по общей для ЦОД VLAN он попадет в соседний, где теперь находится VM; ответ на запрос после обработки последнего в VM будет возвращен по тому же маршруту. Таким образом, вследствие того, что поток данных дважды проходит через так называемые точки перегрузки (Congestion Points), каковыми являются оба конца участки сети, связывающего ЦОД, задержка отклика приложения – ART, – о которой рассказывалось в одной из предыдущих частей блога, может превысить заданный порог, а, следовательно, привести к дискомфорту пользователя. Отсюда вопрос: что нужно предпринять, чтобы исключить прохождение запроса к VM и ответа от нее через «узкое» место – участок сети между ЦОД?

Пожалуй, можно предложить два подхода к решению этой задачи, один из которых основывается на использовании существующих инструментов, а второй – на …Ну об это чуть ниже.

Итак, исходным для первого подхода является понимание того, что IP-адрес VM теперь уже не может служить однозначным указателем на то, в каком из ЦОД в настоящий момент находится VM. Следовательно, следует использовать дополнительный идентификатор, например, еще один IP-адрес (Virtual IP), но который был бы связан уже с ЦОД. Но этого недостаточно – нужен еще процесс, который бы обнаруживал появление VM в данном ЦОД и инициировал установление взаимосвязи между IP-адресом VM и VIP этого ЦОД. Пример того, как данный подход мог бы быть реализован, показан на рис. 4.




Рис. 4




Ключевыми компонентами решения являются DNS-сервер (GSLB(Global Server Load Balancing)), отвечающий за разрешение имен зоны, к которой принадлежат ЦОД; устройства NAT (SLB(Server Load Balancing)), размещающиеся в каждом ЦОД; и управляющий центр виртуальной среды. Пользователь, намеревающийся получить доступ к VM, инициирует DNS-запрос, который, в конечном счете, поступает в GSLB. В ответ GSLB посылает IP-адрес (VIP), принадлежащий устройству NAT того ЦОД, в котором в данный момент находится VM – например, для первого ЦОД пусть это будет VIP #1. Если VM перемещается в другой ЦОД, то управляющий центр – а без него эта операция не может быть выполнена – информирует GSLB о том, что теперь запросы пользователя нужно отправлять по адресу VIP #2, принадлежащий устройству NAT, которое обслуживает этот ЦОД. Получив такое уведомление, GSLB заменяет VIP #1 на VIP #2 в соответствующей А-записи.

В чем достоинства описанного подхода? С моей точки зрения, их два. Во-первых, используются известные, проверенные на практике, технологии – разрешение имен посредством сервиса DNS и виртуализация IP-адреса сервера (VM) с помощью техники трансляции адресов NAT. Во-вторых, подход обладает простотой – это ценное свойство, которое зачастую не принимается в расчет при выборе решения, и, на мой взгляд, напрасно.

Каковы же недостатки? Даже после миграции VM в другой ЦОД, во-первых, потоки данных для уже установленных соединений по-прежнему будут направляться сначала в исходный ЦОД и только затем в тот, куда переместилась VM, и, во-вторых, через исходный ЦОД будут устанавливаться также и новые соединения, если они инициируются пользователем до истечения срока хранения в кэше результатов предыдущих DNS-запросов.

От этих недостатков избавлен второй подход, в основе которого лежит применение новой технологии – LISP (Locator/Identifier Separation Protocol). В рамках этой технологии предусмотрен специальный механизм, который заставляет использовать новый запрос для определения местонахождения VM в случае ее перемещения из исходного ЦОД. В этом случае поток данных, даже связанный с установленным соединением, будет направлен непосредственно в тот ЦОД, куда мигрировала VM.

Однако за такую возможность, конечно, приходится платить увеличением сложности. Ведь LISP базируется на совершенно новой архитектуре маршрутизации, которая, соответственно, включает и новые сущности – ITR (Ingress Tunnel Router), ETR (Egress Tunnel Router), два специальных сервера – Map Server и Map Resolver, а также, разумеется, новые протоколы сигнализации. К этому добавляется еще новый формат кадра для транспортировки данных и два пространства IP-адресов: одно для адресации терминалов – EID (Endpoint Identifiers), другое для решения задачи маршрутизации – RLOC (Routing Locators). Следует принять во внимание и то, что до настоящего времени спецификации этой технологии не стандартизованы, да и реализована она только в продуктах единственного производителя.

Тем не менее, эта технология кажется мне, по меньшей мере, перспективной – ей просто нужно больше времени, чтобы достичь состояния зрелости.

После того, как мы коснулись вопроса оптимизации маршрута следования данных от пользователя к VM, обратим теперь внимание на то, каким может быть обратный путь в том случае, когда уже после установления соединения с пользователем VM перемещается в другой ЦОД. Проблема заключается в том, что в рамках установленного соединения обратный трафик должен пройти тем же путем, что и входящий, но только в обратном направлении, если в обслуживании этого соединения участвуют устройства, сохраняющие сведения о его состоянии, такие, как, например, FW, IPS, SLB. В противном случае, если обратный трафик направить через ближайшие устройства FW, IPS, SLB, то есть те, которые расположены в ЦОД, куда мигрировала VM, то он будет заблокирован, что приведет к разрыву соединения. Это произойдет потому, что для расположенных в другом ЦОД устройств FW, IPS, SLB трафик, который они раньше «не видели», кажется подозрительным или некорректным, а потому и сбрасывается ими.

Проблема «привязки» обратного трафика к исходному ЦОД может быть решена с помощью механизма Source-NAT, как показано на рис. 5.




Рис. 5




Если устройство, выполняющее функцию Source-NAT, находится в той же VLAN, что и VM, то обратный трафик направляется непосредственно к нему через L2-сегмент, связывающий ЦОД, если же в другой VLAN (IP-подсети) – то через шлюз по умолчанию (Default Gateway).

Заметим, что если никаких дополнительных действий не предпринимать, то шлюзом по умолчанию будет тот, который располагается в исходном ЦОД. Это объясняется тем, что при «горячем» перемещении в другой ЦОД VM сохраняет в своем кэше результаты ARP-запросов, в том числе пару значений MAC-адрес/IP-адрес, и для шлюза по умолчанию. Тем не менее, часто бывает необходимо, чтобы поток данных от VM в другие IP-подсети обслуживался шлюзом по умолчанию, локальным для ЦОД, куда переместилась VM. Как этого добиться? Во-первых, шлюзы по умолчанию, находящиеся в каждом из ЦОД, объединяются в так называемую FHRP-группу (First Hop Redundancy Protocol) посредством, например, протокола VRRP (Virtual Router Redundancy Protocol), но при этом сообщения между членами FHRP-группы, находящимися в разных ЦОД, фильтруются. В результате каждый член такой группы функционирует самостоятельно, используя в качестве MAC-адреса и IP-адреса одни и те же значения – vMAC-адрес и vIP-адрес FHRP-группы. И во-вторых, с помощью фильтров блокируется распространение между ЦОД кадров, имеющие в качестве адресов назначения vMAC и vIP. В итоге получаем искомый результат – обработку потока данных от VM посредством локального шлюза по умолчанию.

Непреднамеренно эта часть блога оказалась пространнее предыдущих. Однако и тем, которые были затронуты, тоже было больше. В качестве заключения вспомним вопросы, которых коснулись – «холодный» сценарий перемещения VM между ЦОД; влияние срока кэширования записей DNS на доступность сервисов после миграции VM; «горячий» сценарий перемещения VM между ЦОД; задача L2 Extension и варианты ее решения; использование локального хранилища данных в ЦОД при перемещении VM в другой ЦОД; дополнительные преимущества виртуализации СХД; оптимизация путей для входных потоков данных – от пользователя к приложению – в условиях мобильности VM; оптимизация путей для исходящих потоков данных – от приложения к пользователю – в условиях мобильности VM.

Ряд нюансов, которые, на мой взгляд, также представляют практическую ценность, тем не менее, оказались за рамками этой части блога, например:

• виртуальный коммутатор vSwitch и BPDU;

• коммутация потоков данных между VM – на виртуальном коммутаторе vSwitch или на физическом коммутаторе?;

• насколько полезны режимы HA и FT, предоставляемые виртуальной средой, для обеспечения доступности сервисов?

• применение технологии IP Mobility для поддержки мобильности VM;

• применение технологии RHI для поддержки мобильности VM;

• динамическая настройка профиля порта физического коммутатора в условиях мобильности VM.

Вполне возможно, что мы вернемся к ним позже.

Следующая часть этого блога, по-видимому, станет заключительной, в которой коснемся некоторых возможностей в построении сети ЦОД, возникших с появлением группы стандартов DCB (Data Center Bridging) и протокола доступа к СХД – FСoE.





Просмотров: 89 | Добавил: formennow | Рейтинг: 0.0/0
Всего комментариев: 0
Поиск

Календарь
«  Июль 2013  »
ПнВтСрЧтПтСбВс
1234567
891011121314
15161718192021
22232425262728
293031

Архив записей

Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz


  • Copyright MyCorp © 2017Создать бесплатный сайт с uCoz