Тема этой статьи родилась давно. Мне очень часто задают вопросы о работе тех или иных стораджей, а также о режимах работы их контроллеров, ALUA и политиках multipath в ESXi.
Наконец таки решил написать.
Стораджи бывают разные….
Но я не об этом. Я о режимах работы их контроллеров.
И так в природе есть несколько режимов работы контроллеров (на английском часто называют Storage Processor или SP) у различных СХД — это Active/Passive и Active/Active. Последние еще делятся на SAA и ААА.
Более подробно ниже.
Active/Passive
Старый вариант СХД, сейчас этот вид отживает последний срок. К ним относятся такие стораджи как HP MSA первого поколения, HP EVA (предыдущих поколений), IBM DS 3xxx/4xxx (предыдущих поколений), EMC CLARiiON с CX по СX3 и много других. Суть работы такова. Один из контроллеров является активным и участвует в операциях I/O. Второй контроллер просто находится в ожидающем состояние и не участвует в операциях ввода вывода. Как только произошел сбой или авария (умер контроллер, упали все пути до контроллера и т.п.) активным контроллером становиться пассивный (это происходит автоматически или же выполняется администратором вручную).
Active/Active
Данные класс делиться на два подкласса:
- Symmetrical Active/Active (SAA)
- Asymmetric Active-Active (AAA)
Symmetrical Active/Active (SAA)
Это СХД хайэнд класса уровня enterprise. Очень шустрые, мега функциональные и жутко дорогие. В этих стораджах все контроллеры участвуют в операциях I/O. Причем в таких СХД обычно больше двух контроллеров. К ним относятся такие стораджи как EMC SYMETRIX, HP XP, IBM 8xxx.
Asymmetric Active-Active (AAA)
Самый широкий по моделям класс СХД (начальный и средний уровень). Кстати почти все модели стораджей которые раньше были Active/Passive теперь стали AAA. К примеру таже HP MSA первого поколение, после определенной прошивки (не помню номер), становиться ААА. Сейчас к этому классу относиться HP MSA второго и третьего поколения, HP EVA, IBM DS 3xxx/4xxx/5xxx, EMC CLARiiON CX4 и много других.
Принцип работы AAA стораджей отличается от их старших собратьев SAA. Причем у разных производителей дела обстоят по разному.
В общем схема выглядит так, оба контроллера активны. К определенному контроллеру привязывается LUN (такой контроллер называется owner [владелец] данного LUN). И все операции I/O идут только через контроллер владелец. Путь или пути от HBA до LUN через owner контроллер называются оптимизированными, при этом достигается максимальная производительность. В случае сбоя операции ввода вывода пойдут через другой контроллер не являющийся владельцем LUN. Такие пути или путь называются не оптимизированными и обычно в таких случаях наблюдается потеря производительности. Почему собственно так происходит? Дело в том что, операция I/O идущие через неоптимизированный путь, попадают на второй контроллер, далее второй контроллер по внутренней шине передает их на owner контроллер, тот обрабатывает запросы и передает все в обратном порядке. Такой способ передачи данных по интерконекту не является быстрым, да плюс ко всему живой контроллер обрабатывает еще операции I/O со своими “родными ”LUN, в итоге мы получаем на живом контроллере большую нагрузку.
В этих же стораджах (но не во всех) применяется и еще такая технология как ALUA .
ALUA — Asymmetric Logical Unit Access. Протокол стандарта SCSI-2 и SCSI-3 предоставляющий доступ к данным через разные пути передачи, причем с разными видами доступа. Она также помогает автоматически переключиться на оптимизированные пути.
Итак рассмотрим ситуацию, на СХД имеем два контроллера и два LUN-a, на хосте 2 одно портовых HBA, каждая из которых подключена к контроллеру одним путем.
При сбое путей, автоматически срабатывает failover и данные начинают передаваться через второй контроллер, по неоптимизированным путям.
После того как основные пути поднялись сторадж без ALUA продолжает работать по тем же не оптимизированным путям. Чтобы переключить I/O на оптимизированные пути администратору необходимо выполнить это действие вручную.
Вот тут как раз нам приходит на помощь ALUA, она как раз и занимается тем, что автоматически переключает операции I/O на оптимизированные пути.
Multipath
Я уже писал о политиках multipath в vSphere. Тут снова немного повторюсь.
Для Active/Passive лучше всего подходит политика MRU и она обычно используется, но сразу замечу что и для многих стораджей типа AAA тоже используется MRU. К примеру по умолчанию для IBM DS 3xxx/4xxx сторджей.
Для SAA стораджей используется обычно Fixed, а также можно и нужно использовать Round Robin, так как достигается максимальная производительность. Отдельно напишу о Round Robin чуть ниже.
Для AAA Fixed или же RR.
К слову сказать часто производители стораджей делают свои плагины для multipath, например powerpath для EMC стораджей.
И так round robin лучше всего включать, когда есть несколько путей. В идеально данная политики подходит для SAA стораджей. Мы получаем и повышение производительности и отказоустойчивость.
Также хорошо включать данную политику для AAA стораджей. Благодоря ей мы получим автоматическую работу по всем оптимизированным путям, а также прибавку в производительности. Но особо высокой прибавки в производительности не стоит ожидать при RR на AAA стораджах.
И еще к слову часто читал в интернете что при RR на AAA стораджах наблюдаеться падение производительности. Собственно я ни разу за практику такого не наблюдал, не считая авральных случаев с отваливание всех путей до owner контроллера, но тут и так понятно, что будет потеря.
И на последок несколько рекомендаций для админов AAA стораджей:
- Не вешайте на один контроллер все LUN.
- Планировать SAN так, чтобы был multipath, желательно как минимум по два пути от одного хоста к каждому контроллеру СХД.
- Разделите особо нагруженные LUN по разным контроллерам.
- Используйте политику Round Robin. Если нет родной политики multipath. Перед включение RR на продакшен LUN’ах, протестируйте работу политики на тестовых LUN’ах.
- На AAA стораджах без ALUA, особенно после сбоев, обращайте внимание на warning сообщение СХД о том, что данные идут по неоптимизированным путям.
[…] […]
Про рекомендацию выбора round-robin стоит только добавить, что MSCS\MFC на vSphere не поддерживается при round-robin.
«В случае сбоя операции ввода вывода пойдут через другой контроллер не являющийся владельцем LUN. Такие пути или путь называются не оптимизированными и обычно в таких случаях наблюдается потеря производительности.»
Это смотря КАКОГО сбоя. Если вылетел весь контроллер, то оставшийся контроллер станет владельцем ВСЕХ лунов СХД, и соотв все пути на этот контроллер станут оптимизированными до тех пор, пока в работу не вернется первый контроллер.
2 xxx
Да так и есть, я рассматривал случай падения путей до контроллера, а сам контроллер жив.
2 Михаил
Как то из головы вылетело. Спасибо что напомнил )))
Перечитал несколько раз статью, но так и не понял из нее, чем отличается AAA и ALUA.
Прочитал еще раз и понял)) AAA без ALUA после восстановления после сбоя будет продолжать работать по неоптимизированному пути.
Праздник, однако, разрушает мозг))
Эх видимо праздник, а то я уже думал что я не написал, или написал да не так)))
Вот тут как раз нам приходит на помощь ALUA, она как раз и занимается тем, что автоматически переключает операции I/O на оптимизированные пути.
поправочка: — переключением занимется Power Path, при помощи ALUA. Некоторые MPIO не умеют это делать.
«ALUA, она как раз и занимается тем, что автоматически переключает операции I/O на оптимизированные пути.» — этим занимается MPIO… ALUA-занимается роутингом SCSI команд… 🙂
>поправочка: — переключением занимется Power Path, при помощи ALUA. Некоторые MPIO не умеют это делать.
PowerPath это MPIO от EMC для своих стораджей. У других производителей свои названия MPIO.
>этим занимается MPIO… ALUA-занимается роутингом SCSI команд…
Да, действительно если быть точным и копать ниже, ALUA роутит команды как между путями, так и через интерконект между SP и в паре с MPIO помогает переключатся на оптимизированые пути.
Если говорить про логику, то избыточностью путей и переключением между ними на логическом нижнем уровне занимается MPIO. На стораджах AAA без ALUA, MPIO обычно умеет отрабатывать файловер и переключатся на другие пути, а вот переходить обратно или выбирать оптимизированные пути не умеет, у MPIO нет такой логики.
Собственно про MPIO забыл упомянуть в заметке, просто не стал упоминать данный уровень.
MPIO-это общее название продукта любого вендора по управлению MP. PowerPath — это тоже самое от ЕМС. масло, масленное…. просто у PP функционал развит, поэтому он обратно переключает на хозяина, но смысла это не меняет, я лишь хотел поправить вашу статью в пункте «ALUA, она как раз и занимается тем, что автоматически переключает операции I/O на оптимизированные пути.»
Думаю мы поняли д.д!
Отличная статья, побольше бы такого уровня спецов у нас в КЗ )
Да конечно поняли. Спасибо за отзыв и дельные комментарии 🙂
Коллеги, а про SAА можно пару слов? Каким образом происходит одновременный доступ к луну (ну или тому — зависит от вендора) обоих контроллеров? Блокируется ли лун на кратковременный период выполнения команд конкретного контроллера?
Заранее спасибо.
В общем все SAA СХД работает примерно так. I/O идут по всем путям на все SP, которые в свою очередь связаны между собой внутренней шиной, как и в их младших братьях — СХД AAA, но очень быстрой. ПО СХД отслеживает нагрузку по путям, нагрузку на SP и на LUN-ах и автоматически балансирует поток данных между контроллерами по внутренней шине и затем сбрасывает все через наименее загруженный SP на диски, чтение и отдача данных примерно также – наименее загруженный SP читает данные, если необходимо по внутренней шине перекидывает часть на другой SP, затем все данные отдаются по всем свободным путям.
Собственно у каждого вендора подобные механизмы реализованы по разному и как это реализовано именно внутри конкретной SAA СХД обычно покрыто тайной. Если говорить о блокировках — никаких привычных блокировок там нет. Блокировки идут на уровне ОС\гипервизора и их файловой системы работающего на стороне сервера и использующего LUN-ы.
Михаил, большое спасибо за оперативный ответ!
Хочу попытаться прояснить для себя еще пару моментов.
1. Не первый раз встречаю в подобных этой статьях о AAA/SAA, что в SAA интерконнект «очень» или «невероятно» быстрый. Он быстрый сам по себе или по сравнению с интерконектов в AAA СХД? Просто, например, в NetApp (соотв. все FAS СХД — это вроде как AAA) это InfiniBand, т.е. он классифицируется как медленный? А что тогда «очень быстро»? 🙂
2. По поводу блокировок я спросил именно про блокировку луна или тома внутри самой СХД (внутри ОС — это понятно, но это уже на уровне файлов). Я очень плохо себе предсавляю, как это работает, но, как мне кажется, в конечном итоге вся очередь ввода-вывода на лун будет укладываться последовательно в конечнную шину, по которой подключены жесткие диски (например, SAS) в RAID-группе(ах), на которой лежит этот лун. То есть, не очень понятно, почему, например, не влияют на проихводительность такие вещи, когда IOPS’ы поступают на лун вне очереди (со второго SP, пришедшие чуть позже, чем с первого)? Примерно также, как может произойти в ТСР соединении, когда сегменты приходят на конечный узел в неупорядоченном виде и этот узел вынужден ждать те TCP сегменты, которые приходят с задержкой, чтобы собрать полный кусок данных вышележащего приложения…
Начну с того что до сути трудно докопаться, потому что как работает та или иная СХД на нижних уровнях знают только R&D инженера ее разрабатывающие и вендора не любят делится этой информацией.
Инфинибэнд да быстрая шина, но не самая. Кроме быстроты интерфейса\шины, есть зависимость от архитектура SP, софта и как интерконекты реализованы.
Интерконекты в SAA СХД быстрые, обычно очень быстрые и их архитектура немного отличается от тех же интерконектов AAA СХД. К примеру, если мне не изменяет память, в DS 8xxxx между SP используется очень шустрая прямая процессорная шина как и в больших Power машинках. Интерконекты в AAA СХД по проще и по дешевле.
Собственно на самом деле есть еще один большой и важный момент кроме интерконекта, на сегодняшний день интерконект относительно быстрый даже в средних и топовых AAA CХД, а важен софт, оптимизация этого софта для железа на котором он исполняется и которым он управляет. Не секрет что половина стоимости любой СХД это софт, а в некоторых случаях и моделях СХД различных вендоров стоимость софта превышает 60-70% всей стоимости СХД.
Вот как раз софт за все отвечает за всю логику, и даже в одной модели СХД разные версии софта могут работать по различным алгоритмам.
Большинство современных СХД это те же самые серверы x86 архитектуры, перепакованные в другие корпусы с некоторыми не хитрыми дополнениями, с ОС внутри, поверх которой софт отвечающий за всю логику, к примеру у Netapp это ONTAP – модифицированная когда то FreeBSD с софтом собственной разработки. Исключением являются топовые high-end СХД некоторых вендоров, например IBM DS8000 там SP уже сервера Power на RISC CPU и с AIX-ом внутри, поверх которого опять же софт.
Немного отвлекся… возвращаюсь к дискуссии
Опять же все зависит от вендора и версий софта. Общий принцип на сколько мне известно был такой. I/O приходят по всем путям на разные SP, софт следит за нагрузкой всех SP, путей, дисков, групп рейдов и т.п. Часть данных с LUN кешируется в RAM SP, это как на чтение так и на запись, так и на операции по дедупликации и д.р операции, если есть кеш в виде SSD то туда тоже кешируются данные обычно на запись и чтение.
Софт собирает пришедшие команды и данные, смотрит какой SP наименее загружен, перекидывает обработку на него и затем через такой SP скидывает на LUN. В случае с SSD кешем данные проходят и через них, и в конце уже скидываются на нужный LUN лежащий на каких либо дисках. Поэтому как таковых блокировок нет на уровне SP. Обычно софт следит, чтобы SP были равномерно загружены и не допускает перекоса загрузки конкретного SP, перекосы бывают, но очень маленькие, которые выравниваются при следующих операциях.
И в этой картине два узких места – производительность софта\SP и конечных дисков. Первое оптимизируется за счет оптимизации софта, а также за счет наращивание мощностей SP в виде более мощных CPU, более быстрой RAM и большего ее объема. Второе оптимизируется как выше уже писал за счет SSD дисков для кеша и правильным сайзингом под конкретные задачи, ну и некоторыми другими вещами. Поэтому тут упереться в ширину каналов бекэндов или каналов той же SAN практически нереально. Последнее реально, если SAN спроектирована и построена не правильно.
Для меня как архитектора, да и для большинства инженеров SAN не обязательно в точности знать, как работает нижний уровень софта и железа. Как уже в начале комментария писал, мы и не узнаем до конца. Главные моменты, следующие в любой СХД: цена, производительность, функционал, возможность выполнить поставленные задачи, возможности по масштабированию различных аспектов СХД, например полок, дисков, производительности, а также удобство управления, обслуживания и интеграция с необходимыми железом и софтом в общей массе проекта. И конечно лучше сочетание всех этих качеств.