Симпатичная Золушка ищет небогатого принца без вредных привычек::Журнал СА 7-8.2017
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 10470
Комментарии: 11
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 10905
Комментарии: 13
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 17794
Комментарии: 2
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 16344
Комментарии: 13
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 17140
Комментарии: 7
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Симпатичная Золушка ищет небогатого принца без вредных привычек

Архив номеров / 2017 / Выпуск №7-8 (176-177) / Симпатичная Золушка ищет небогатого принца без вредных привычек

Рубрика: Администрирование /  Хранение данных

Алексей Бережной АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, alexey.berezhnoy@tech-center.com

Симпатичная Золушка ищет
небогатого принца без вредных привычек

Всегда ли система хранения данных стоит больших денег и накладных расходов? А можно обойтись малыми затратами и создать СХД силами небольшого ИТ-отдела? На помощь приходит протокол AoE

Симпатичная Золушка ищет небогатого принца без вредных привычекЭта статья посвящена системам хранения данных, которые, к моему глубокому сожалению, пока не слишком распространены. Несмотря на четко очерченные преимущества и ожидаемые ограничения, у их создателей не получилось напустить рекламной шумихи и прочего «промоушена», что, в свою очередь, повлияло на широту использования.

Сразу скажу: стандарт, описываемый в данной статье, не слишком подходит для использования в огромных центрах обработки данных (ЦОД). На сегодняшний день оперативные решения, предназначенные для использования по принципу «взять и сделать, здесь и сейчас», находятся в роли Золушки.

Кстати, о сказке про Золушку. Представьте на минуту, что принц из этой сказки умудрился разбить (или потерять) хрустальную (или меховую) туфельку. То есть необходимость в невесте есть, мало того, жениться очень хочется, а подходящий критерий, увы, четко не определен. Вот тут-то и наступает самое подходящее время для наглой жадной мачехи и ее капризных и ленивых дочерей, чтобы подсунуть гораздо менее симпатичное, зато широко разрекламированное предложение. Примерно такая ситуация происходит при выборе оборудования для небольших компактных решений. Нужно подключить считанное количество серверов к SAN, чтобы предоставить некоторое общее пространство, а широко себя рекламирующие вендоры СХД предлагают исключительно дорогостоящие системы, при этом еще имеющие ограничение как с точки зрения лицензии, так и с точки зрения обеспечения поддержки, при этом требующие дополнительного обучения специалистов за весьма немалые деньги.

И вот сейчас мы плавно подходим к главным героям нашего повествования. Представим себе, что нам не нужно создавать колоссальную распределенную систему SAN между удаленными ЦОД. И у нас нет большого числа серверов. И нам не нужно бороться за каждый дополнительный IOPS [1] и FLOPS [2], потому что наши задачи, в целом обыденные для средней компании. И у нас не самые жесткие требования к отказоустойчивости, и бизнес без особых проблем переживет согласованный перерыв в работе в год на несколько часов для диагностики и замены оборудования.

И самое главное. Допустим, у нас всегда есть хотя бы одна актуальная копия хранимых данных. Поэтому если из нашего оборудования внезапно пойдет дым, для организации это будет неприятно, но не смертельно. (Да, я знаю, что у многих российских айтишников существует устойчивое мнение о том, что бэкап делают только трусы и неуверенные в себе новички, а настоящие «крутые спецы» надеются исключительно на отказоустойчивые решения из разряда High Availability, а также на свою гениальность и экстрасенсорные способности. Но тем не менее именно у нас актуальная копия будет всегда...)

Терминология

Согласно традиции мы будем использовать уже ставшие стандартными соглашения о терминологии, пришедшие из SCSI-стандарта.

  • Initiator. Под этим названием будем понимать устройство-клиент, запрашивающее процедуру чтения, сохранения данных или аналогичную. Имеет такое название, потому что является инициатором взаимодействия при обмене илиреорганизации хранения данных. Именно initiator выбирает целевое устройство хранения для выполнения с ним тех или иных действий.
  • Target. Этот термин обозначает целевое устройство, предоставляющее свои ресурсы для хранения данных. Носит данное название, потому что является целью (англ. – target) при выборе со стороны инициатора (initiator).

Примечание. Следует отметить, что роли 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-версию данного номера можно приобрести в нашем магазине.


  1. Описание IOPS – http://dic.academic.ru/dic.nsf/ruwiki/1701078.
  2. Как узнать производительность компьютера в Флопсах (Flops) – http://youon.ru/Компьютеры-ПО/kak-uznat-proizvoditelnost-kompyutera-v-flopsakh-flops.
  3. Описание модели ISO/OSI на Citforum – http://citforum.ru/nets/protocols/1_01_02.shtml.
  4. Официальный сайт Institute of Electrical and Electronics Engineers (IEEE) – http://www.ieee.org.
  5. Бережной А. Применение iSCSI при построении систем хранения данных. //«Системный администратор», № 3, 2017 г. – С. 10-15 (http://samag.ru/archive/article/3383).
  6. Остапчук Е. Что такое VLANs? Сети VLAN – http://fb.ru/article/144516/chto-takoe-vlans-seti-vlan.
  7. Бережной А. FCoE как попытка компромисса. //«Системный администратор», № 6, 2017 г. – С. 18-21 (http://samag.ru/archive/article/3447).
  8. Бережной А. Построение SAN на базе протокола Fibre Channel. //«Системный администратор», № 12, 2016 г. – С. 4-7 (http://samag.ru/archive/article/3329).
  9. Бережной А. Не теряя управления. //«Системный администратор», № 5, 2014 г. – С. 22-25 (http://samag.ru/archive/article/2685).
  10. Официальный сайт компании Coraid – http://coraid.com.
  11. Страничка ATA over Ethernet Tools на Sourceforge – https://sourceforge.net/projects/aoetools.
  12. StarWind AoE Initiator. ATA-over-Ethernet Initiator for Microsoft Windows – https://www.starwindsoftware.com/aoe-ataoverethernet-initiator.
  13. Что такое Jumbo Frame? Cправочник по сетевым стандартам, протоколам, технологиям – http://admin-gu.ru/network/chto-takoe-jumbo-frame.
  14. Те самые 12 страниц описания спецификации AoE – http://brantleycoilecompany.com/AoEr11.pdf.
  15. Борисов A. Протоколы сетей хранения данных. Часть 1. ATA over Ethernet (AoE). //«Системный администратор», № 9, 2005 г. – С. 76-78 (http://samag.ru/archive/article/554).
  16. Бережной А. Сохранение данных: теория и практика. – М.: Издательство «ДМК-Пресс». – 2016 – http://dmkpress.com/catalog/computer/securuty/978-5-94074-185-3.
  17. Бирюков А. Информационная безопасность: защита и нападение. Второе издание. – М.: Издательство «ДМК-Пресс». – 2016 – http://dmkpress.com/catalog/computer/securuty/978-5-97060-435-9.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru