ЦОД. Часть 6. Перспективы сети хранения данных

11.02.2013 | Ганус Сергей
Want create site? Find Free WordPress Themes and plugins.

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

Что же, попытаемся рассмотреть возможные варианты. Сегодня, пожалуй, можно порассуждать о перспективах 3-х технологий, в основе которых лежат протоколы FC, FCoE и iSCSI.

Вряд ли ошибусь, если скажу, что у нас, когда речь идет о централизованном хранении данных, наибольшее распространение получила технология FC (строго говоря, FC – это стек протоколов, но для простоты будем использовать термин «технология»). Чем это объяснить? Выдающейся производительностью? Вначале – да. Действительно, технология FC могла обеспечить скорость обмена данными 2 Gbps, 4 Gbps или 8 Gbps, в то время как технология iSCSI – всего лишь 1 Gbps. Кроме того, поначалу и задержки при доступе к СХД посредством технологии iSCSI были заметно выше, поскольку упаковка-распаковка команд и блоков данных SCSI в пакеты TCP и IP осуществлялась без аппаратной поддержки – эти операции выполнялись процессорами сервера и контроллера СХД. Чем еще? Надежностью – без потерь кадров данных и в строгом порядке их следования – транспортировки данных между сервером и СХД, что крайне важно для обеспечения производительности приложений, когда много серверов, обслуживающих эти приложения, обращаются к одной СХД. В то время протокол Ethernet этого дать не мог. Ну и третья причина заключается в том, что исторически технология FC родилась лет на 10 раньше технологии iSCSI и в силу этого оказалась в свое время единственным выбором при организации доступа к СХД. Следствием этого явилось то, что к моменту появления технологии iSCSI уже существовала значительная база SAN с FC-коммутаторами и СХД с FC-интерфейсами, к которым администраторы привыкли и не спешили менять на что-то новое, незнакомое и незрелое. И, по-моему, они были правы, заняв взвешенную позицию.

Однако, прошло время, и теперь ситуация изменилась, чему способствовали 2 фактора. Во-первых, это появление интерфейса 10 GE, что позволило обеспечить примерно то же значение пропускной способности при обмене данными между сервером и СХД, что и технология FC с интерфейсом 8 Gbps (в Интернете в избытке отчетов о тестах на тему производительности FC и iSCSI). Теоретическое же преимущество технологии FC перед iSCSI в количестве IOPS на практике обнаруживается в специальных случаях – ну при очень интенсивных запросах случайного характера к ну очень огромным базам данных, которые накопили компании из списка Fortune 500. Разумеется, это не наш случай. Во-вторых, это разработка протоколов Ethernet, входящих в группу DCB (Data Center Bridging) – IEEE 802.1 Qbb (Priority-based Flow Control), IEEE 802.1 Qaz (Enhanced Transmission Selection) и IEEE 802.1 Qau (Quantized Congestion Notification), предоставивших возможность обеспечить ту же самую степень надежности транспортировки команд и блоков данных SCSI, которая характерна для технологии FC.

Таким образом, при данных обстоятельствах технология FC уже не обладает теми преимуществами по сравнению с технологией iSCSI – производительностью и надежностью транспортировки данных, – которые она демонстрировала изначально. Однако теперь, когда парированы недостатки технологии iSCSI, на первый план выходит уже преимущество последней, которое заключается в стоимости ее применения. А это такой козырь, которому крайне трудно что-либо противопоставить. Кстати, вся история развития информационных технологий (а, пожалуй, и не только информационных) пестрит примерами, когда менее совершенные, но зато куда более дешевые технологии получали доминирующее положение на рынке. Меньшая стоимость использования технологии iSCSI определяется двумя факторами. Во-первых, стоимость коммутатора Ethernet даже с поддержкой стандартов группы DCB значительно меньше стоимости коммутатора FC. Во-вторых, и, на мой взгляд, это гораздо более интересная особенность, поскольку теперь для обслуживания всех видов взаимодействия, а именно: рабочая станция – сервер, сервер – сервер и сервер – СХД, можно использовать один и тот же протокол канального уровня Ethernet, и, следовательно, появляется возможность в ЦОД использовать всего одну сеть – LAN, а не две, как ранее – LAN и SAN. Важным следствием этого, на мой взгляд, является снижение объема знаний, необходимых для эксплуатации сетевой инфраструктуры в ЦОД – ведь технология FC разительно, включая терминологию, принципы действия и семейство протоколов, отличается от технологий, применяемых в LAN. А значит, появляется возможность уменьшить и количество администраторов, тем самым несколько смягчив проблему их тотальной нехватки, особенно квалифицированных.

Есть еще одно обстоятельство, которое следует иметь в виду, когда стоит вопрос о том, чтобы расширить SAN на основе технологии FC на несколько ЦОД. Дело в том, что технология FC имеет ограничение по расстоянию, на котором могут располагаться друг от друга ЦОД. Если быть уж совсем точным, то пропускная способность SAN на основе технологии FC вследствие используемого механизма управления потоком данных – BB_сredits – находится в обратно пропорциональной зависимости от расстояния между наиболее удаленными FC-коммутаторами, и, следовательно, существует такое предельное значение дистанции, превышение которого критическим образом сказывается на скорости обмена данными между сервером и СХД или между СХД и СХД. Другими словами, расположение ЦОД друг от друга на расстоянии, большем сверх некоторого определенного значения, теоретически возможно, но практически малопривлекательно. Для решения все же такой задачи используется технология FCIP, которая позволяет в соответствии с RFC 3821 локализовать действие механизма управления потоком данных BB_сredits в рамках отдельного ЦОД, и тем самым разорвать жесткую зависимость производительности FC-SAN от расстояния между ЦОД. Однако в этом случае возникает другая проблема – несоответствие размеров кадра FC (2148 байт) и MTU в IP-сетях (как правило, 1500 байт), – которая приводит к росту задержек (читать «уменьшению производительности») при обмене данными вследствие необходимости выполнения операции фрагментации-дефрагментации IP-пакетов, требующей значительных вычислительных ресурсов. И следует позаботиться о …, конечно же, о приобретении пары устройств для каждого ЦОД, способных поддерживать технологию FCIP.

Это обстоятельство – задача организации SAN между несколькими ЦОД, – на мой взгляд, должно дополнительно стимулировать размышление на тему «а есть ли жизнь» … с iSCSI?

С моей точки зрения, применение iSCSI-SAN позволяет: а) получить производительность не меньшую, чем та, которой обладают FC-SAN, б) упростить сетевую инфраструктуру ЦОД, в) удешевить ее, и г) с использованием группы стандартов DCB демонстрировать такую же степень надежности транспортировки данных между сервером и СХД, что и FC-SAN. И это все факторы, которые благоприятствуют применению в ЦОД iSCSI-SAN.

А что препятствует? На мой взгляд, существуют два аспекта. Один из них – человеческий фактор, а точнее, известный консерватизм администраторов: «Зачем менять то, что хорошо работает»? Второй аспект – технологический. Ведь при переходе от FC-SAN к iSCSI-SAN вряд ли удастся исключить период, когда оба типа SAN используются в ЦОД, и при этом требуется предоставить возможность серверу с любым интерфейсом – FC или iSCSI – получить доступ к наборам данных, которые могут быть размещены на СХД, включенных в любую из SAN.

Как известно, действие первого из указанных факторов преодолевается труднее всего – обычно должны произойти некоторые события, которые могут сказаться на точке зрения администраторов. Со вторым фактором дело обстоит намного проще: можно предложить рассмотреть применение контроллеров виртуализации СХД, о которых упоминалось в предыдущей части блога. Эти устройства помимо того, что скрывают от серверов технические особенности СХД, могут еще и выполнять функции шлюза протоколов. Другими словами, сервер с интерфейсом iSCSI может хранить данные на СХД с интерфейсом FC, также как сервер с FC HBA – на СХД с интерфейсом iSCSI, как показано на схеме на рис. 1.

Рис. 1. ЦОД с двумя типами SAN – FC-SAN и iSCSI-SAN

  Бонус – контроллер виртуализации СХД способен создавать зеркальные тома, один из которых, например, может располагаться на СХД с FC-интерфейсом, а другой – на СХД с iSCSI-интерфейсом, и автоматически переключать запросы сервера на резервный том в случае выхода из строя основного.

Если подытожить, то ответ на вопрос, сформулированный в начале этой части блога, заключается в том, что факторы, рассмотренные выше, на мой взгляд, формируют тенденцию все большего распространения в ЦОД SAN на основе технологии iSCSI.

Что же касается перспектив протокола FCoE, который также упоминался в начале этой части блога, но временно был «забыт», то, по-моему, их можно охарактеризовать как весьма не радужные. Действительно, что такое протокол FCoE? Это попытка заменить физический и канальный уровни стека протоколов FC, соответственно FC0 и FC1, одноименными уровнями IEEE 802.3, то есть Ethernet. Что это дает? Возможность построить в ЦОД единую сеть с универсальным канальным уровнем Ethernet и уменьшить количество кабелей, подводимых к серверам. Что в минусе? В общем случае в коммутаторах Ethernet, из которых состоит такая единая сеть, должна присутствовать поддержка функции FCF (Fibre Channel Forwarder), то есть, в одном коммутаторе необходимо реализовать, по существу, два виртуальных – коммутатор Ethernet с поддержкой протоколов группы DCB и коммутатор FC. Таким образом, сетевая инфраструктура ЦОД с функциональной точки зрения проще не стала, если не считать исчезновение уровней FC0 и FC1; и хотя отказ от использования физических коммутаторов FC уменьшает стоимость сетевой инфраструктуры, но реализация виртуального коммутатора FC на базе физического коммутатора Ethernet ее же и повышает. По существу, технология FCoE – это тупик.

Во всяком случае, хочется привести цитату из одного из блогов 2010-го года Чака Холиса (Chuck Hollis) – одного из руководителей компании EMC, которую трудно заподозрить в предвзятости в отношении к какой-либо из трех упомянутых технологий: «Use FC where you feel you need to, use Ethernet [NFS, CIFS, iSCSI] everywhere else – and save money and effort in the process». По-русски, это примерно звучит так: «Применяйте FC, когда чувствуете, что без этого не обойтись, во все остальных случаях используйте Ethernet [по контексту, NFS, CIFS, iSCSI] – и Вы сохраните деньги и усилия».

Did you find apk for android? You can find new Free Android Games and apps.
Комментариев пока нет
Добавить комментарий