Всегда странно представлять себе времена, когда чего-то не было. Сложно сегодня представить себе, как мы жили без персональных компьютеров, без интернета, без торрентов, mp3, или без электрокопировальных аппаратов, в просторечии «ксероксов». Тем не менее всегда были времена, когда что-то привычное нам еще не существовало. Также обстояло дело и с понятием «снэпшота данных». Но сперва — что же такое «снэпшот»?

"Снэпшот" (дословно — «фотография», «моментальный снимок», здесь и далее под этим словом мы будем понимать конкретно, не уточняя, «снэпшот данных») это моментальная копия состояния данных в системе хранения, или программе, зафиксированная на определенный момент времени. Это может быть моментальное состояние содержимого файла, базы данных, или файловой системы (как частного случая «базы данных»).
В применении к системам хранения данных этот термин появился вместе с первыми системами хранения NetApp и был, на тот момент первой и главной их «фичей».

Когда я в прошлом посте написал, что Snapshots были, на момент появления систем NetApp их главной «фичей», я отчасти слукавил (а отчасти просто забыл), так как у них, на тот момент, была как минимум еще одна особенность, радикально выделяющая их из ряда «традиционных» систем хранения — это «RAID тип 4».
Это тем более интересно, так как никто больше такой тип RAID для использования в дисковых системах хранения данных не использует.
Почему же был выбран именно такой тип, в чем его преимущества, и почему никто больше такой тип RAID сегодня не использует?

Использование Flash-памяти для современных систем хранения стало уже почти повседневным делом, понятие SSD — Solid-State Disk, широко вошло в практику энтерпрайз-систем хранения и серверов. Более того, для многих понятия Flash и SSD стали едва ли не синонимами. Однако, NetApp не был бы собой, если бы не нашел для использования Flash лучший, свой собственный способ его использования.
Как же можно использовать Flash для системы хранения, но НЕ в виде SSD?

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

Облачные файловые хранилища продолжают набирать популярность, и требования к ним продолжают расти. Современные системы уже не в состоянии полностью удовлетворить все эти требования без значительных затрат ресурсов на поддержку и масштабирование этих систем. Под системой я подразумеваю кластер с тем или иным уровнем доступа к данным. Для пользователя важна надежность хранения и высокая доступность, чтобы файлы можно было всегда легко и быстро получить, а риск потери данных стремился к нулю. В свою очередь для поставщиков и администраторов таких хранилищ важна простота поддержки, масштабируемость и низкая стоимость аппаратных и программных компонентов.

Знакомьтесь: Ceph

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



При выходе любого диска, узла или группы узлов из строя Ceph не только обеспечит сохранность данных, но и сам восстановит утраченные копии на других узлах до тех пор, пока вышедшие из строя узлы или диски не заменят на рабочие. При этом ребилд происходит без секунды простоя и прозрачно для клиентов.

Этот мануал написан для желающих попробовать гибкость и удобство распределенного файлового хранилища Ceph в виртуальной среде на домашнем ПК. Сразу поясню, что 10 минут — это время на разворачивание самого кластера (установка и настройка Ceph на виртуальных машинах). Но на создание и клонирование виртуальных машин и на установку ОС потребуется отдельное время.

К концу статьи у нас будет виртуальный кластер из трех машин, и сам ПК с Windows в качестве клиента хранилища. Следом мы скинем туда фотографии котиков, уроним одну ноду, потом поднимем, уроним другую, скачаем обратно фотографии котиков, обрадуемся.

Кто еще не в теме Ceph, можно прочитать вводную статью Знакомство с Ceph в картинках и посмотреть модное промо от производителя.

В этой статье мы проведем небольшой обзор наиболее популярных протоколов, которые используются для построения сетей хранения данных (SAN). Также рассмотрим перспективы развития и использования отдельных протоколов, опираясь на общедоступные роудмапы производителей.

Несколько дней назад стала доступна версия Data ONTAP 8.3.2RC1. “RC” означает Release Candidate, а следовательно, в соответствии с принятыми в NetApp правилами именования версий, этот релиз уже прошел все внутренние тесты и может использоваться заказчиками не только для оценки новых возможностей, но и для продуктива, включая системы, на которых работают бизнес-критичные задачи. Поддержка вендора полностью распространяется на системы, работающие на “RC” версиях Data ONTAP.

Продавцы NetApp (да, это и мы тоже ;) не устают напоминать (и делают это совершенно правильно), что высокая утилизация дисковых ресурсов в системах NetApp достигается за счет использования программных средств оптимизации — дедупликации и компрессии.

Компания VMware завершила длительную и кропотливую работу над новой концепцией СХД выпуском в свет vSphere 6.0 с поддержкой программных хранилищ и структуры Virtual Volumes (VVols), о которых и будет мой сегодняшний пост. Начну с официального определения от производителя: «Virtual Volumes — это новая структура интеграции и управления, обеспечивающая виртуализацию массивов SAN и NAS благодаря созданию эффективной эксплуатационной модели, которая оптимизирована для виртуализированных сред и ориентирована на особенности приложения, а не инфраструктуры».

Представляется, что в будущем Virtual Volumes заменят VMFS, поскольку VMware никогда не распыляется на поддержку двух различных вариантов для ключевых компонентов инфраструктуры, то есть на двойную работу. Сперва они упразднили ESX спустя несколько лет после выхода ESXi, затем – VSA, выпустив на замену VSAN, а теперь пытаются перевести пользователей с vSphere Client на Web Client; допускаю, что в какой-то момент они могут решить перейти от vCenter Server на Windows к VCSA. Поэтому можно предположить, что аналогичная судьба ждет VMFS, от которой откажутся в пользу VVols – разумеется, после того, как они достигнут определенной стадии «зрелости» и будут приняты к использованию большинством пользовательской аудитории. Подтверждением этой мысли является и тот факт, что поддержка VVols включена во все редакции vSphere.

Выясним, однако, для начала, почему эксперты советуют не торопиться с внедрением Virtual Volumes.

Традиционные облачные решения для резервного копирования и восстановления данных часто уже не устраивают предприятия в силу ряда причин. Компания NetApp предлагает сегодня своим клиентам линейку решений класса Cloud-Integrated Storage семейства AltaVault.

В большинстве случаев шифрование диска является излишним или даже вредным. Однако, когда дело касается ноутбука, паранойя не помешает. Получив в руки новый ноутбук, именно шифрованием диска я первым делом и озаботился.

На данный момент во многих дистрибутивах уже из коробки предоставляется возможность создавать шифрованные разделы. Однако, все те варианты, что мне попадались, предусматривают нешифрованный /boot. Не критичное, но неприятное упущение. Информация о том, как сделать полностью шифрованный диск, ищется в интернете достаточно легко, но подавляющая её часть на английском языке и некоторые подводные камни всё же не описаны. Я постараюсь наиболее кратко, понятно и по шагам объединить эту информацию в одном тексте.

В этой статье я хотел бы рассмотреть внутреннее устройство и архитектуру технологии vVol, реализованную в системах хранения данных NetApp с прошивкой ONTAP.

Почему появилась эта технология и зачем она нужна, почему она будет востребована в современных ЦОД? На эти и другие вопросы я постараюсь ответить в этой статье.

Технология vVol предоставила профили, которые при создании ВМ создают виртуальные диски с заданными характеристиками. В такой среде администратор виртуальной среды уже может с одной стороны у себя в интерфейсе vCenter легко и быстро проверить, какие виртуальные машины живут на каких носителях и узнать их характеристики на СХД: какой там тип носителя, включена ли для него технология кеширования, выполняется ли там репликация для DR, настроена ли там компрессия, дедупликация, шифрование и т.д. С технологией vVol, СХД стала просто набором ресурсов для vCenter, намного более глубже интегрировав их друг с другом, чем это было раньше.

Снепшоты

Проблема консолидации снепшотов и увеличение нагрузки на дисковую подсистему от снепшотов VMware может быть не заметна для небольших виртуальных инфраструктур, но даже они могут встречаться с их негативным влиянием в виде замедления роботы виртуальной машины или невозможности консолидации (удаление снепшота). vVol поддерживает аппаратный QoS для виртуальных дисков ВМ, а также Hardware-Assistant репликацию и снепшоты NetApp, так как они архитектурно устроены и принципиально по-другому работают, не влияя на производительность, в отличие от COW снепшотов VMware. Казалось бы кто пользуется этими снепшотами и почему это важно? Дело в том, что все схемы резервного копирования в среде виртуализации так или иначе архитектурно вынуждены использовать COW снепшоты VMware, если вы хотите получить консистентные данные.

Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.

Описание технологии VVOL

Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.

Во время ежегодной конференции для партнёров и заказчиков NetApp Insight было объявлено о выходе новых систем хранения данных, работающих под управлением операционной системы ONTAP. Обновились системы FAS и AFF.

Вместе с выходом нового оборудования будет доступна новая версия ONTAP — 9.1.
Для начала разберёмся, что же нового в железе.

FAS. Всем FlashCache. Первые СХД с 40GbE и 32Gb FC

Начнём с обновления гибридных массивов FAS. Выходит 4 новые модели: FAS2620, FAS2650 — системы начального уровня, FAS8200 — система среднего уровня для корпоративных заказчиков и FAS9000 — high-end система с абсолютно новым (для NetApp) подходом в построении шасси.

Новые системы стали существенно производительнее:

• Используются новые процессоры Intel на архитектуре Broadwell
• Доступно больше кэша и NVRAM
• NVMe FlashCache
• В старших контроллерах доступны интерфейсы 40GbE и 32Gb FC
• Для подключения дисков используется SAS-3 12Gb

Дедупликация данных — это технология, при помощи которой обнаруживаются и исключаются избыточные данные в дисковом хранилище. В результате это позволяет сократить объёмы физических носителей для хранения тех же объёмов данных.
Дедупликация данных это одна из самых «горячих» тем в области систем хранения данных последних двух-трех лет. Ведь очевидно, что в том гигантском объеме данных, который сейчас приходится хранить современным системам хранения, неизбежно встречаются дубликаты и идентичные данные, за счет устранения которых можно было бы значительно сократить объемы хранения.
Пожалуй наибольшего успеха снискали реализации технологий дедупликации в области систем дискового резервного копирования (например EMC Avamar, Data Domain), однако компания NetApp первой объявила о возможности использования дедупликации для так называемых «primary storage», то есть основного, «боевого» хранилища активных данных, так как смогла предложить технологию дедупликации, практически не снижающую производительность его работы.
Сегодня я бы хотел рассказать как и за счет чего это удалось, и почему пока не получается у других.

В своем первом посте в этом блоге я обещал рассказать вам о NetApp «с технической стороны». Однако прежде чем рассказать о большинстве из имеющихся в системах NetApp возможностей, мне придется рассказать о «фундаменте», о том, что лежит в основе любой системы хранения NetApp — о специальной структуре организации данных, которую традиционно принято называть «файловой системой WAFL» — Write Anywhere File Layout — Файловой Структурой с Записью Повсюду, если перевести дословно.

Если вы сочтете, что «для Хабра» текст суховат, то потерпите, дальше будет интереснее, но не рассказать об устройстве того, что лежит в основе подавляющего большинства практических «фич» NetApp я не могу. В дальнейшем будет куда сослаться «для интересующихся» на подробное объяснение в следующих постах, о более практических «фишках».
Так, или иначе, но почти все, что NetApp умеет уникального растет именно из придуманной в начале 90-х Дэвидом Хитцем и Джеймсом Лау, сооснователями «стартапа» Network Appliance, файловой системы. Хороший аргумент за то, насколько важной и полезной может оказаться в будущем развитии изначально грамотная и продуманная «архитектура» продукта.

Вот уже около 20 лет назад в жизнь IT-отделов компаний вошло понятие SAN — Storage Area Network или специализированная сеть устройств хранения данных. Использование централизованных хранилищ, на которых размещаются используемые на серверах приложений их дисковые разделы, подключенные по специальным высокоскоростным протоколам, позволило значительно повысить эффективность и гибкость использования дискового пространства.

Причины, стоявшие за созданием SAN, отчасти были теми же, что стояли ранее за созданием обычной локальной сети LAN и shared-устройств в ней. Вместо того, чтобы давать каждому клиентскому компьютеру по лазерному принтеру, который будет простаивать в 99% времени, лучше дадим ему доступ к коллективно используемому принтеру, пусть более мощному и дорогому, но используемому с более высокой средней загрузкой, и тем самым повысим уровень использования ресурса и его экономическую эффективность.
В том числе использование «общего дискового ресурса» решило и проблему «недоиспользования». Если минимально доступный диск SATA на сегодня обычно не менее 500GB, то если мы не используем его для хранения накачанного из торрентов видео, то обычно, в рядовом использовании, он пуст на 90-95%. Типовая установка OS занимает 2-8 GB, приложения и его данные еще сколько-то, чаще всего несколько гигабайт, все же остальное пространство остается свободным, но увы, недоступным для, возможно, нуждающихся задач на других компьютерах.

В этом году я решил, что обязательно должен попробовать написать на Хабр.

По роду своей деятельности я немного занимаюсь системами виртуализации и как сопутствующим — системами хранения данных, на которых виртуальные машины и обитают. Соответственно, имелся небольшой опыт в настройке SAN сетей и некоторых СХД производства HP.

Но было в моем ведомстве еще две волшебные пары контроллеров NetApp, работающих в 7-Mode. Занимался я исключительно их поддержкой, выделением LUN и имел базовое представление о том, как это все работает изнутри.

Бэкапы нужно проверять.

В качестве вступления простая история из бурной молодости. Всем знакома ситуация, когда ресурсов нет, а хранить резервные копии нужно. В свое время для хранения резервных копий своих систем, использовалось два диска объемом по 500GB. Как можно было догадаться, при использовании RAID-1, полезное пространство ограничивалось теми самыми 500GB, чего катастрофически не хватало. Было принято решение использовать Linux LVM, тем самым получить 1000GB пространства, в ущерб надежности.

На протяжении года, а может и больше, резервные копии складывались на данный ресурс, скрипты отчитывались о том, что все хорошо, а список бэкапов при просмотре содержимого директории радовал глаз.

Наступил час Х, и нужно было восстанавливаться, удивлению не было предела, когда один из бэкапов был поврежден, ведь все говорило о том, что бэкапы делаются, хранятся, и в целом все хорошо. Как позже выяснилось, один из дисков, состоящих в LVM начал сыпаться, часть данных можно было восстановить, а другую часть уже нет. Никогда не делайте так, как это делал в свое время я.

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

Тем, кому интересно как Veeam проверяет свои резервные копии, прошу под кат.

Бэкапы нужно иметь. Желательно, в нескольких местах.

Я думаю, что каждый администратор Veeam Backup & Replication замечал в консоли управления кнопку «Add Service Provider». На Хабре есть несколько хороших статей, которые демонстрируют, как использовать эту кнопку по назначению и как начать складывать бэкапы Veeam не только у себя, но и в облако, предоставленное сервис-провайдером.

В этой статье я бы хотел попытаться заглянуть по ту сторону и показать, что нужно сделать самому сервис-провайдеру, чтобы начать принимать резервные копии клиентов.