Начнем с основ. Как же работают устройства на технологи SCSI? В стандарте SCSI все построено на концепции клиент/сервер.
Клиент, называемый инициатором (англ. initiator), отправляет разные команды и дожидается их результатов. Чаще всего, разумеется, в роли клиента выступает SAS контроллер. Сегодня SAS контроллеры — это HBA и RAID-контроллеры, а также контроллеры СХД, стоящие внутри внешних систем хранения данных.
Сервер называется целевым устройством (англ. target), его задача — принять запрос инициатора, обработать его и вернуть данные или подтверждение выполнения команды обратно. В роли целевого устройства может выступать и отдельный диск, и целый дисковый массив. В этом случае SAS HBA внутри дискового массива (так называемая внешняя система хранения данных), предназначенный для подключения к нему серверов, работает в режиме Target. Каждому целевому устройству (“таргету”) присваивается отдельный идентификатор SCSI Target ID.
Для связи клиентов с сервером используется подсистема доставки данных (англ. Service Delivery Subsystem), в большинстве случаев, это хитрое название скрывает за собой просто кабели. Кабели бывают как для внешних подключений, так и для подключений внутри серверов. Кабели меняются от поколения к поколению SAS. На сегодня имеется три поколения SAS:
— SAS-1 или 3Gbit SAS
— SAS-2 или 6Gbit SAS
— SAS-3 или 12 Gbit SAS – готовится к выходу в середине 2013 года
Внутренние и внешние кабели SAS
Иногда в состав этой подсистемы могут входить расширители или экспандеры SAS. Под экспандерами (англ. Expanders, расширители, но в русском языке прижилось слово «экспандер») понимают устройства, помогающие доставке информации от инициаторов к целям и обратно, но прозрачные для целевых устройств. Одним из самых типичных примеров является экспандер, позволяющий подключить несколько целевых устройств к одному порту инициатора, например, микросхема экспандера в дисковой полке или на бэкплейне сервера. Благодаря такой организации, серверы могут иметь более 8 дисков (контроллеры, которые сегодня используются ведущими производителями серверов, обычно 8-портовые), а дисковые полки – любое необходимое количество.
Инициатор, соединенный с целевым устройством системой доставки данных, называют доменом. Любое SCSI устройство содержит как минимум один порт, который может быть портом инициатора, целевого устройства или совмещать обе функции. Портам могут присваиваться идентификаторы (PID).
Целевые устройства состоят из как минимум одного логического номера устройства (Logical Unit Number или LUN). Именно LUN и идентифицирует с каким из дисков или разделов данного целевого устройства будет работать инициатор. Иногда говорят, что target предоставляет инициатору LUN. Таким образом, для полной адресации к нужному хранилищу используется пара SCSI Target ID + LUN.
Как в известном анекдоте («Я не даю в долг, а Первый Национальный Банк не торгует семечками») — целевое устройство обычно не выступает в роли «посылающего команды», а инициатор — не предоставляет LUN. Хотя стоит отметить, что стандарт допускает тот факт, что одно устройство может быть одновременно и инициатором и целью, но на практике это используют мало.
Для «общения» устройств в SAS существует протокол, по «доброй традиции» и по рекомендации OSI, разделенный на несколько слоев (сверху вниз): Application, Transport, Link, PHY, Architecture и Physical.
SAS включает в себя три транспортных протокола. Serial SCSI Protocol (SSP) — используется для работы со SCSI устройствами. Serial ATA Tunneling Protocol (STP) — для взаимодействия с дисками SATA. Serial Management Protocol (SMP) — для управления SAS-фабрикой. Благодаря STP мы можем подключать диски SATA к контроллерам SAS. Благодаря SMP мы можем строить большие (до 1000 дисковых/SSD-устройств в одном домене) системы, а также использовать зонирование SAS (подробнее об этом в статье про SAS-коммутатор).
Уровень связей служит для управления соединениями и передачи фреймов. Уровень PHY — используется для таких вещей как установка скорости соединения и кодировки. На архитектурном уровне находятся вопросы расширителей и топологии. Физический уровень определяет напряжение, форму сигналов соединения и т.д.
Все взаимодействие в SCSI строится на основании команд, которые инициатор посылает целевому устройству и ожидает их результата. Команды эти посылаются в виде блоков описания команды (Command Description Block или CDB). Блок состоит из одного байта кода команды и ее параметров. Первым параметром почти всегда выступает LUN. CDB может иметь длину от 6 до 32 байт, хотя последние версии SCSI допускают CDB переменной длины.
После получения команды целевое устройство возвращает код подтверждения. 00h означает что команда принята успешно, 02h обозначает ошибку, 08h — занятое устройство.
Команды делятся на 4 большие категории. N, от английского «non-data», предназначены для операций, не относящихся к непосредственно обмену данными. W, от «write» — запись данных, полученных целевым устройством от инициатора. R, как не сложно догадаться от слова «read» используется для чтения. Наконец В — для двустороннего обмена данными.
Команд SCSI существует достаточно много, поэтому перечислим только наиболее часто используемые.
Test unit ready (00h) — проверить, готово ли устройство, есть ли в нем диск (если это ленточный накопитель), раскрутился ли диск и так далее. Стоит отметить, что в данном случае устройство не производит полной самодиагностики, для этого существуют другие команды.
Inquiry (12h) — получить основные характеристики устройства и его параметры
Send diagnostic (1Dh) — произвести самодиагностику устройства — результаты этой команды возвращаются после диагностики командой Receive Diagnostic Results (1Ch)
Request sense (03h) — команда позволяет получить статус выполнения предыдущей команды — результатом этой команды может стать как сообщение типа «нет ошибки», так и разные сбои, начиная с отсутствия диска в накопителе и заканчивая серьезными проблемами.
Read capacity (25h) — позволяет узнать объем целевого устройства
Format Unit (04h) — служит для деструктивного форматирования целевого устройства и подготовки его к хранению данных.
Read (4 варианта) — чтение данных; существует в виде 4 разных команд, отличающихся длиной CDB
Write (4 варианта) — запись. Так же как и для чтения в 4 вариантах
Write and verify (3 варианта) — запись данных и проверка
Mode select (2 варианта) — установка различных параметров устройства
Mode sense (2 варианта) — возвращает текущие параметры устройства
А теперь рассмотрим несколько типичных примеров организации хранения данных на SAS.
Пример первый, сервер хранения данных.
Что это такое и с чем его едят? Большие компании типа Amazon, Youtube, Facebook, Mail.ru и Yandex используют сервера этого типа для того, чтобы хранить контент. Под контентом понимается видео, аудио информация, картинки, результаты индексирования и обработки информации (например, так популярный в последнее время в США, Hadoop), почта, и.т.д. Для понимания задачи и грамотного выбора оборудования под нее нужно дополнительно знать несколько вводных, без которых никак нельзя. Первое и самое главное – чем больше дисков – тем лучше.
Дата-центр одной из российских Web 2.0-компаний
Процессоры и память в таких серверах задействуются не сильно. Второе – в мире Web 2.0, информация хранится географически распределено, несколько копий на различных серверах. Хранится 2-3 копии информации. Иногда, если она запрашивается часто, хранят больше копий для балансировки нагрузки. Ну и третье, исходя из первого и второго, чем дешевле – тем лучше. В большинстве случаев все вышесказанное приводит к тому, что используются Nearline SAS или SATA диски высокой емкости. Как правило, Enterprise-уровня. Это значит, что такие диски предназначены для работы 24×7 и стоят значительно дороже своих собратьев, использующихся в настольных PC. Корпус обычно выбирают такой, куда можно вставить побольше дисков. Если это 3.5’’, то 12 дисков в 2U.
Типичный 2U-сервер хранения данных
Или 24 x 2.5’’ в 2U. Или другие варианты в 3U, 4U и.т.д. Теперь, имея корпус, количество дисков и их тип, мы должны выбрать тип подключения. Вообще-то выбор не очень большой. А сводится он к использованию экспандерного или безэкспандерного бэкплейна. Если мы используем экспандерный бекплейн, то контроллер SAS может быть 8-портовым. Если безэкспандерный – то количество портов контроллера SAS должно равняться или превышать количество дисков. Ну и последнее, выбор контроллера. Мы знаем количество портов, 8, 16, 24, например и выбираем контроллер исходя из этих условий. Контроллеры бывают 2х типов, RAID- и HBA. Отличаются они тем, что RAID-контроллеры поддерживают уровни RAID 5,6,50,60 и имеют достаточно большой объем памяти (512MB-2ГБ сегодня) для кэширования. У HBA памяти или cовсем нет, или ее очень мало. Кроме этого, HBA либо не умеют делать RAID вообще, либо умеют олько простые, не требующие большого объема вычислений уровни. RAID 0/1/1E/10 – типичный набор для HBA. Здесь нам нужен HBA, они стоят значительно дешевле, так защита данных нам не нужна совсем и мы стремимся к минимизации стоимости сервера.
16-портовый SAS HBA
Пример второй, почтовый сервер Exchange. А также MDaemon, Notes и другие подобные сервера.
Здесь все не так очевидно, как в первом примере. В зависимости от того, сколько пользователей должен обслуживать сервер, рекомендации будут различными. В любом случае, мы знаем что базу данных Exchange (так называемую БД Jet) лучше всего хранить на RAID 5/6 и она неплохо кэшируется с использованием SSD. В зависимости от количества пользователей определяем необходимые объемы хранения «сегодня» и «на вырост». Помним, что сервер живет 3-5 лет. Поэтому «на вырост» можно ограничить 5-летней перспективой. Потом будет дешевле полностью поменять сервер. В зависимости от объема дисков выберем корпус. С бэкплейном проще, рекомендуется использовать экспандеры, так как требования по цене не такие жесткие, как в предыдущем случае, и в общем случае, удорожание сервера на $50-$100, а иногда и больше, мы вполне переживем в угоду надежности и функциональности. Диски выберем SAS или NL-SAS/Enterprise SATA в зависимости от объемов. Далее, защита данных и кэширование. Выберем современный 4/8-портовый контроллер, поддерживающий RAID 5/6/50/60 и кэширование на SSD. Для LSI, это любой MegaRAID кроме 9240 с функцией кэширования CacheCade 2.0, или Nytro MegaRAID с SSD «на борту». Для Adaptec, это контроллеры, поддерживающие MAX IQ. Для кэширования в обоих случаях (кроме Nytro MegaRAID) нужно будет взять пару SSD на e-MLC-технологии Enterprise-класса. Такие есть у Intel, Seagate, Toshiba, и.т.д. Цены и компании – на выбор. Если вы не порч доплатить за бренд, то в линейках серверов IBM, Dell, HP, найдите подобные продукты и вперед!
SSD- кэширующий RAID-контроллер Nytro MegaRAID
Пример третий, внешняя система хранения данных своими руками.
Итак, самое серьезное знание SAS, конечно же, требуется тем, кто производит системы хранения данных или хочет их сделать своими руками. Мы остановимся на достаточно простой СХД, программное обеспечение для которой производится компанией Open-E. Конечно же, можно делать СХД и на Windows Storage Server, и на Nexenta, и на AVRORAID, и на Open NAS, и на любом другом подходящем для этих целей софте. Я просто обозначил основные направления, а дальше вам помогут сайты производителей. Итак, если это внешняя система, то мы почти никогда не знаем, сколько же дисков потребуется конечному пользователю. Мы должны быть гибкими. Для этого есть так называемые JBOD – внешние полки для дисков. В их состав входит один или два экспандера, каждый из которых имеет вход (4-х портовый разъем SAS), выход на следующий экспандер, остальные порты разведены на разъемы, предназначенные для подключения дисков. Причем, в двухэкспандерных системах первый порт диска разведен на первый экспандер, второй порт – на второй экспандер. Это позволяет строить отказоустойчивые цепочки JBOD-ов. Головной сервер может иметь внутренние диски в своем составе, либо не иметь их совсем. В этом случае используются «внешние» контроллеры SAS. То есть контроллеры с портами «наружу». Выбор между SAS RAID-контроллером или SAS HBA зависит от управляющего ПО, которое вы выбираете. В случае Open-E, это RAID-контроллер. Можно позаботиться и об опции кэширования на SSD. Если ваша СХД будет иметь очень много дисков, то решение Daisy Chain (когда каждый последующий JBOD подключается к предыдущему, либо к головному серверу) в силу многих причин не подходит. В этом случае головной сервер либо оснащается несколькими контроллерами, либо используется устройство, которое называется SAS-коммутатор. Он позволяет подключать один или несколько серверов к одному или нескольким JBOD. Подробнее SAS-коммутаторы мы разберем в следующих статьях. Для внешних систем хранения данных настоятельно рекомендуется использовать диски только SAS (в том числе NearLine) в силу повышенных требований к отказоустойчивости. Дело в том, что протокол SAS имеет в своем составе гораздо больше функций, чем SATA. Например, контроль записываемых-считываемых данных на всем пути с помощью проверочных сумм (T.10 End-to-End protection). А путь, как мы уже знаем, бывает очень длинным.
Многодисковый JBOD
Напоследок, хочется поделиться некоторыми сведениями о текущей адаптации SAS мировыми производителями оборудования. SAS сегодня – это стандарт де-факто для серверных систем и профессиональных рабочих станций. Серверные системы подавляющего большинства как A- так и B- брендов имеют в составе контроллеры SAS, как HBA, так и RAID. В области внешних систем хранения данных, основные производители оборудования (HP, EMC, NetApp, IBM) уже несколько лет как перевели внутренние архитектуры своих систем на SAS. Таким образом, диски Fibre Channel стали за последние пару лет настоящей экзотикой. Fibre Channel продолжает жить и развиваться, в основном, как способ подключения серверов к системам хранения данных, хотя в области Low-End, Mid-Range и профессиональных систем, SAS отвоевывает все большую долю.
На этом наш экскурс в мир истории и теории SCSI вообще и SAS в частности подошел к концу, и в следующий раз я расскажу вам более подробно о применении SAS в реальной жизни.
ссылка на оригинал статьи http://habrahabr.ru/post/175313/
Добавить комментарий