Представленный ниже материал содержит значительное количество технических терминов, при переводе которых могут возникнуть неточности. Если вы заметили опечатку, ошибку или неточность перевода — напишите нам, и мы оперативно всё исправим.
Важно понимать, что используемые в настоящий момент интерфейсы SAS и SATA — не более, чем эволюционировавшие технологии SCSI и ATA, которые развиваются на протяжение десятилетий. С тех пор серверные технологии ушли далеко вперед, а потребность в приложениях для обработки данных значительно увеличилась.
Очевидно, что представители индустрии должны задуматься о дальнейшей модернищации существующих технологий хранения данных. Однако, задача по выжиманию большего количества IOPS из SSD больше относится к науке, с практической точки зрения куда важнее вопрос общей стоимости владения средствами хранения данных.
В больших компаниях все острее стоит вопрос организации хранения данных — особенно в регулируемых отраслях, участники которых обязаны хранить данные на протяжении длительного времени согласно законодательным нормам. Кроме того, эта информация должна быть легкодоступна — это усложняет использование технологий архивирования.
Говоря прямо, SAN и NAS стоят кучу денег, и на них уходит до трети всех затрат на «железо» в дата-центрах компаний. Да, производители таких продуктов заработали себе отличную репутацию, поэтому их продукцию используют для хранения самых критически важных данных, но давайте будем честны — в этих забитых дисками коробках размером с рефрижератор нет никакой магии.
Внутри все те же SATA, SAS, различные интерфейсы, контроллеры и специальный софт, который отвечает за создание логических номеров устройств (LUN). Большинство этих контроллеров работают на проприетарных версиях UNIX или даже разновидностях BSD — пользователь никогда ничего из этого не увидит. Для него SAN или NAS после создания LUN — это настоящий черный ящик.
Этому дорогущему безумию можно положить конец, но для этого необходим нестандартный и креативный подход представителей крупного бизнеса — это значит, что они должны относиться к хранилищу также, как это делают поставщики масштабируемых услуг (hyperscale). Когда мы говорим о масштабировании, то подразумеваем Amazon Web Services, Microsoft Azure или Google Computer Engine.
Вы же думаете, что этим компаниям удалось создать облачные системы хранения данных исключительно с помощью железа EMC и NetApp?
Конечно же нет, это просто невозможно. Вместо SAN и NAS такие компании используют JBOD — массивы «просто дисков» (Just a Bunch of Disks). Им удалось создать более дешевую инфраструктуру с помощью общедоступного и недорогого оборудования, JBOD и опытных инженеров.
Не существует никаких стандартов построения таких инфраструктур, к тому же этот процесс осложняется тем фактом, что исторически сложилось мнение о необходимости использования оптоволокна для создания кластеризованных хранилищ — а это до сих пор очень затратно.
Однако благодаря Ethernet-сетям 10Gigabit и 40Gigabit, Ethernet-картам RDMA и появлению сетевого протокола доступа SMB 3.0 ситуация быстро меняется.
Концепция довольно проста — организация просто подключает множество «голов» файловых серверов к имеющейся скоммутированной Ethernet-инфраструктуре, и использует множество JBOD (их делают, к примеру, DataOn, Dell или Supermicro), составленных из SAS 15K и SSD, в ярусной конфиругации и соединенных с этими «головами» в SAS-кластере.
В свою очередь эти якорные файл-серверы соединены с виртуализированными или физическими системами, которые обеспечивают доступ к данных с помощью SMB 3.0. Эластичность такой системы зависит от ОС, управляющей хранилищем, а не от какого-то секретного софта, встроенного в контроллеры, как это сделано в SAN и NAS.
В сценарии, который описан на изображении выше, использованы файл-серверы Microsoft Scale-out File Server (SoFS), которые поставляются с встроенной Windows Server 2012 R2, и используют для работы компонент Storage Spaces. В качестве железа здесь задействованы DataOn DNS-1660D в комбинации со стоечными серверами Dell R820 и картами Mellanox RDMA.
Описанная выше конфигурация способна достигать постоянной скорости более 1 млн IOPS в секунду.
Публикацию о построении SoFS-массивов JBOD с помощью MD1220 PowerVault выпустила Dell. В общем-то, работать будет любая комбинация JBOD, распространенного железа архитектуры x86 с использованием SAS и Ethernet-соединения 10 Гбит/с.
Помимо Microsoft существуют и другие вендоры, занимающиеся построением архитектур, основанных на JBOD — например, Nexenta (на основе ZFS от Solaris), для Linux есть HA-LVM и GFS/GFS2, включающие компонент Resilient Storage от Red Hat. Эквивалент для Ubuntu Server называется ClusterStack.
Вывод здесь заключается в том, что несмотря на надежность и проверенность решений SAN и NAS их гегемония в деле обеспечения наивысшей производительности и «упругости» хранилищ подходит к концу, и скоро широко будут распространены и другие инструменты.
Руководители компаний, которые стремятся сэкономить на хранении все возрастающего объёма данных уже в ближайшем будущем могут прибегнуть к способу, который применяют облачные провайдеры — использованию JBOD и software defined storage (про это, кстати, на Хабре была статья), встроенных в современные серверные ОС, и применению хранилищ, интегрированных с облаком (CIS) для тех приложений, которым позволительно хранение бэкапов в облаке.
Комментарии (3)
ximik13
29.04.2015 06:42ZFS имеет ряд собственных нюансов и далеко не идеальна. Если использовать ее не разобравшись в этих нюансах, то и данные потерять не долго. Не говоря уже про всякие тонкости и оптимизации для достижения хорошей производительности и т.д. Достаточно вчитаться вот в этот документ от разработчиков FreeNAS.
Как пример:
For maximum performance and reliability, you should never try to use ZFS with less than 8GB of RAM and a 64-bit system under any circumstances, regardless of the size of your pool. We typically see at least 1-2 people every week that break this rule and they lose their pools suddenly. There is no recovery if you damage your pool and ignoring this warning.
It is not recommended that VDevs contain more than 11 disks under any circumstances.
FreeNAS’ ZFS stripes data in chunks up to 128 kilobyte. If you will be using compression (default is enabled/lz4) with FreeNAS 9.2.1+ then the following slide does not apply. Compression adds a layer of complexity because each block of data will be compressed to some arbitrary smaller size, so planning for ideal block allocation is impossible.
For home users in particular, your bottleneck is certainly going to be your Gb NIC and not your pool unless you are using woefully inadequate hardware for FreeNAS.
А сама статья оставляет впечатление, что автор не в курсе, что большие вендоры тоже давно смотрят на сегмент Scale-out систем хранения и на программно определяемые СХД. И на рынке давно уже разносолье готовых решений (из коробки) на эту тему и за ваши деньги. Не все компании могут позволить себе держать штат высококвалифицированных программистов и админов, что бы пилить собственное решение под себя. По этому наравне с классическими решениями хранения, те же самые компании продвигают и продают так называемые «легко масштабируемые» Scale-out и software defined storage. A SMB 3.0 от мелкомягких не единственный протокол в мире IT, годный для получения доступа к хранимым данным ;).
Adnako
Причём статистика показывает, что SAS не сильно-то надёжней SATA
Вообще ноль магии — для рукастых есть OpenIndiana, для обычных — Nexenta
Не, не нужен — есть уже готовые к продакшену системы, нет денег — собери сам, мало денег — иди к нексенте.
ZFS божественна, все рейды — фуфло.
amarao
Последний раз, когда я смотрел на luminos, она вела себя крайне неприлично при любых пертурбациях в районе SAS-шины. mpt2sas для соляриса ещё хуже, чем в линуксе.