 |
|
|
|
Симпатичная Золушка ищет небогатого принца без вредных привычек
Симпатичная Золушка ищет Всегда ли система хранения данных стоит больших денег и накладных расходов? А можно обойтись малыми затратами и создать СХД силами небольшого ИТ-отдела? На помощь приходит протокол AoE
Сразу скажу: стандарт, описываемый в данной статье, не слишком подходит для использования в огромных центрах обработки данных (ЦОД). На сегодняшний день оперативные решения, предназначенные для использования по принципу «взять и сделать, здесь и сейчас», находятся в роли Золушки. Кстати, о сказке про Золушку. Представьте на минуту, что принц из этой сказки умудрился разбить (или потерять) хрустальную (или меховую) туфельку. То есть необходимость в невесте есть, мало того, жениться очень хочется, а подходящий критерий, увы, четко не определен. Вот тут-то и наступает самое подходящее время для наглой жадной мачехи и ее капризных и ленивых дочерей, чтобы подсунуть гораздо менее симпатичное, зато широко разрекламированное предложение. Примерно такая ситуация происходит при выборе оборудования для небольших компактных решений. Нужно подключить считанное количество серверов к SAN, чтобы предоставить некоторое общее пространство, а широко себя рекламирующие вендоры СХД предлагают исключительно дорогостоящие системы, при этом еще имеющие ограничение как с точки зрения лицензии, так и с точки зрения обеспечения поддержки, при этом требующие дополнительного обучения специалистов за весьма немалые деньги. И вот сейчас мы плавно подходим к главным героям нашего повествования. Представим себе, что нам не нужно создавать колоссальную распределенную систему SAN между удаленными ЦОД. И у нас нет большого числа серверов. И нам не нужно бороться за каждый дополнительный IOPS [1] и FLOPS [2], потому что наши задачи, в целом обыденные для средней компании. И у нас не самые жесткие требования к отказоустойчивости, и бизнес без особых проблем переживет согласованный перерыв в работе в год на несколько часов для диагностики и замены оборудования. И самое главное. Допустим, у нас всегда есть хотя бы одна актуальная копия хранимых данных. Поэтому если из нашего оборудования внезапно пойдет дым, для организации это будет неприятно, но не смертельно. (Да, я знаю, что у многих российских айтишников существует устойчивое мнение о том, что бэкап делают только трусы и неуверенные в себе новички, а настоящие «крутые спецы» надеются исключительно на отказоустойчивые решения из разряда High Availability, а также на свою гениальность и экстрасенсорные способности. Но тем не менее именно у нас актуальная копия будет всегда...) Терминология Согласно традиции мы будем использовать уже ставшие стандартными соглашения о терминологии, пришедшие из SCSI-стандарта.
Примечание. Следует отметить, что роли Initiator и Target не являются неизменными, существует практика, когда два взаимодействующих компонента SAN выступают поочередно то в одной, то в другой роли, например, при осуществлении операций репликации или резервного копирования. Протокол ATAoE и его реализация ATA over Ethernet (AoE или ATAoE) – это специализированный протокол, работающий на втором уровне модели ISO OSI [3]. Имеет зарегистрированный номер в IEEE [4] – 0x88a2. Основная идеология, заложенная в данный протокол, заключается в организации транспорта для эмуляции посредством Ethernet внешних систем хранения как обычных ATA (SATA) дисков. Данный протокол изначально создавался для сетей Ethernet, ограниченных одним широковещательным доменом. Это означает, что и клиенты (initiators), и устройства хранения (targets) работают в рамках одного фрагмента сети передачи данных. Классический пример – когда все участники обмена данными подключены к одному коммутатору без разделения на сегменты (VLAN). Следует отметить, что протоколы передачи данных второго уровня не способны обеспечить усиленный контроль целостности передаваемой информации по сравнению с TCP/IP. Как известно, стек протоколов TCP/IP изначально был создан для организации надежной передачи данных через ненадежные сети. Следует учесть, что чем выше уровень контроля и надежности, тем выше нагрузка ложится на вычислительный блок компьютера. И все это для того, чтобы приспособить достаточно сложный набор протоколов для решения простых задач. Хорошим примером такого нагромождения служит протокол iSCSI [5]. Использование iSCSI позволяет передать команды и данные SCSI-протокола, используя в качестве транспорта TCP/IP, что, в свою очередь, дает возможность заменить дорогое оборудование Fibre Channel на относительно недорогие коммутаторы семейства Ethernet. Однако очень часто приходится строить iSCSI-инфраструктуру с применением устройств, поддерживающих функцию разгрузки вычислительного блока от обслуживания TCP (TCP offload engines, TOE). Эти устройства (например, сетевые адаптеры) стоят не так уж и дешево. В то же время сплошь и рядом возникают ситуации, когда без таких устройств трудно обойтись, так как они позволяют снять часть нагрузки по обслуживанию TCP/IP с центрального процессора на узлах, подключенных к iSCSI SAN. Замечательным является тот факт, что решения на базе iSCSI часто применяются для небольших инфраструктур, когда использование внешних сетей, например сети Интернет, не планировалось вовсе. Зато нужно обеспечить как можно большую скорость передачи данных на самое дальнее расстояние – в другой угол серверной. При этом какие-то дополнительные методы защиты данных вроде брандмауэров и ACL на коммутаторах 3-го уровня будут совершенно излишни. Отдельно стоит отметить стоимость и функциональные возможности коммутатора. Чаще всего «интеллектуальные способности» дорогого коммутатора 3-го уровня так и остаются невостребованными. В лучшем случае используется разделение на VLAN [6], при этом маршрутизация трафика между отдельными сегментами чаще всего не требуется. Разумеется, сейчас мы говорим о сети для связи по линии initiator – target, а никак не для доступа пользователей ксерверным ресурсам. Подведя промежуточные итоги, трудно не прийти к выводу, что использование протоколов TCP/IP и iSCSI в рамках простых инфраструктур выглядит не слишком хорошим решением. Но есть и другие протоколы SAN, не зависящие от TCP/IP. Например, можно вспомнить небезызвестный FCoE. Но тут возникает другая проблема. Решения на основе FCoE достаточно «капризны». Например, требуется применение коммутатора 10 Gigabit Ethernet, поддерживающего расширенные функции, необходимые для поддержки FCoE. Обо всем об этом можно прочесть в моей статье о FCoE [7]. Кроме всего прочего, необходимы технические специалисты сдостаточно высоким уровнем квалификации. Разумеется, можно пойти по другому пути и просто закупить классический вариант в виде полного комплекта для организации сети Fiber Channel [8], включая внутренние адаптеры для серверов (HBA), FC-коммутаторы (fabric) иоптоволоконные кабели (FC patch-cords). На самом деле это очень хороший вариант, однако достаточно дорогой. Если финансы позволяют, то вариант с Fiber Channel, наверное, будет лучшим решением для многих ситуаций. Однако чаще всего приходится довольствоваться более дешевыми альтернативами. Подытожив все вышесказанное, постепенно приходим к выводу, что для несложных организации, экономически целесообразно иметь решение, отвечающее трем критериям:
Протокол AoE служит ответом на вышеперечисленные условия. Его создатели отказались от использования сложной системы контроля целостности в TCP/IP, возложив ответственность за передачу данных на оборудование Ethernet-коммутаторов последних (или хотя бы не самых старых) моделей. А почему бы и нет? Если вы используете современное сетевое оборудование, то проблемы передачи данных внутри локальной сети, например коллизии, уже не актуальны. Для современных LAN нет необходимости контролировать последовательность пакетов, при этом контрольная сумма подсчитывается для каждого пакета. В целом принципы организации AoE во многом напоминают FCoE. Точно так же вся основная работа происходит на втором уровне модели ISO/OSI, точно так же возможно использовать VLAN для сегментирования сети, и точно так же нет нужды преобразовывать трафик в IP и далее в TCP-пакеты и обратно. Однако AoE не содержит многих сложных вещей, например не требует дополнительных вспомогательных протоколов, как FIP (FCoE Initiation Protocol). Итак, методы организации AoE несколько проще, чем, например, FCoE и тем более iSCSI, так как здесь не используются многие инструменты, обязательные для «классических» решений SAN. Статью целиком читайте в журнале «Системный администратор», №7-8 за 2017 г. на страницах 32-35. PDF-версию данного номера можно приобрести в нашем магазине.
|
АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
