/ фото Intel Free Press CC

Тренды, связанные с изменениями в области облачных технологий и дата-центров, говорят сами за себя.

Мы в 1cloud работаем над собственным облачным сервисом и не можем обойти стороной происходящие перемены. По данным Gartner в 2016 году на облачные ресурсы придется значительная часть трат бюджета большей части ИТ-компаний, а Cisco говорит о том, к 2018 году 78% вычислительных задач будут обрабатываться облачными дата-центрами.

Компания 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.

Закон Мура говорит об увеличении производительности в 2 раза каждые 2 года при сохранении стоимости устройств. Данная гипотеза не перестает порождать различные споры.

Это перевод ответа на вопрос о влиянии свободного пространства на диске на производительность с сайта superuser.com — прим. переводчика



От автора: Похоже, я случайно написал целую книгу. Налейте себе чашку кофе перед чтением.

Ускоряет ли освобождение дискового пространства ваш компьютер?

Освобождение дискового пространства не ускоряет компьютер, по крайней мере не само по себе. Это действительно распространённый миф. Этот миф так распространён, потому что заполнение вашего жёсткого диска часто происходит одновременно с другими процессами, которые традиционно могут замедлить* ваш компьютер. Производительность SSD может снижаться по мере заполнения, однако это сравнительно новая проблема, свойственная SSD, и, в действительности, малозаметная для простых пользователей. В общем случае, недостаток свободного места — просто красная тряпка для быка (отвлекает внимание — прим. переводчика).

Компании Google, eBay и AliExpress согласились хранить персональные данные своих российских пользователей на серверах в России, сообщил глава Роскомнадзора Александр Жаров на расширенном заседании коллегии ведомства в понедельник. Он напомнил, что с 1 июля 2015 года вступает в силу федеральный закон, согласно которому размещение на территории России серверов обязательно, а с 1 сентября начнет действовать закон, обязывающий хранить данные россиян внутри страны.

«Новые требования вызвали широкий общественный резонанс, но Роскомнадзор провел ряд встреч с бизнесом, разъяснили основные термины и обсудили основные проблемные вопросы, — пояснил Жаров. — В результате исполнять требования российского законодательства уже согласились такие компании, как eBay и AliExpress. Google, как мне известно, также намерен соблюдать эти требования».

[ источник ]

Продолжу, первая часть тут.

Кластер

Итак, приступим к настройке софта, управляющего кластером.
У нас это будет Pacemaker + Corosync в качестве транспортного бэкенда для общения между нодами.
Corosync для большей надёжности поддерживает работу через несколько колец обмена данными.
Причём, три и более уже не тянет, хотя в доках про это нигде особо не указано, только ругается при запуске если указать более двух в конфиге.

Кольца названы так потому что общение между нодами идёт по кольцу — ноды передают данные друг другу последовательно, заодно проверяя живучесть друг друга. Работает оно по UDP, может как по мультикасту, так и по уникасту. У нас будет последний, почему — будет понятно ниже.

Кольца

Для связи между нодами я решил применить несколько параноидальную схему — внешнее кольцо через коммутаторы (тут стандартный Bonding/Etherchannel на два свича) + внутреннее кольцо, соединяющее ноды напрямую (напомню, что их три — два хранилища + свидетель).

Схема следующая:


Зелёные связи — внутреннее кольцо, чёрные — внешнее. В данной топологии ноды должны будут сохранить связность даже при полном отказе внешних устройств (шторм положил коммутаторы, админ (то бишь я) своими кривыми руками что-то напортачил… маловероятно, но всё может быть).

ownCloud, как утверждает Википедия — это Свободное и открытое веб-приложение для синхронизации данных, расшаривания файлов и удалённого хранения документов в «облаке». И, как мне кажется, довольно интересное решение для организации собственного домашнего облака.

Однако, ownCloud, устанавливающийся в виде плагина в системе FreeNAS, да и просто из коробки, имеет ряд недостатков, от которых хотелось бы избавится даже при использовании дома:

• Во-первых, устанавливается в связке с SQLite, что подходит только если у вас небольшое кол-во файлов и пользователей, и абсолютно не подходит, если вы планируете синхронизацию с помощью клиента. У меня же хранилище уже расползлось почти на 5Tb и установленный таким образом ownCloud просто отказывался видеть часть файлов. Да и без синхронизации отдача от облака не велика. Заменим базу данных на MariaDB.
• Во-вторых, отсутствует работа по https, а мне совсем не нравится мысль о том, что кто-то может перехватить мои файлы. Включим https.
• В-третьих, начисто отсутствует защита от банального подбора пароля методом брутфорса. Защитимся от брутфорса с помощью fail2ban.
• В-четвёртых, мне лень часто просматривать логи на предмет взлома, но очень хочется оперативно узнавать о таких попытках. Настроим push-оповещения о попытках подбора пароля с помощью сервиса pushover.net.

Героем этого обзора будет скромная система хранения данных DotHill 4824. Наверняка многие из вас слышали, что DotHill в качестве OEM-партнёра производит СХД начального уровня для Hewlett-Packard — те самые популярные HP MSA (Modular Storage Array), существующие уже в четвёртом поколении. Линейка DotHill 4004 соответствует HP MSA2040 с небольшими различиями, которые будут подробно описаны ниже.

DotHill — это классическая СХД начального уровня. Форм-фактор, 2U, два варианта под разные диски и с большим многообразием хостовых интерфейсов. Зеркалируемый кэш, два контроллера, ассиметричный active-active с ALUA. В прошлом году добавился новый функционал: дисковые пулы с трёхуровневым tiering'ом (ярусным хранением данных) и SSD-кэшом.

Аннотация

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

Вторая часть

Итак, продолжу свои редкие статьи на тему «как не платить HP/EMC/IBM многие кило-(или даже мега-) доллары и собрать своё хранилище не хуже». Прошлый цикл я до победного конца не довёл, но 90% мыслей всё же оформил в текст.

Нашей сегодняшней целью будет отказоустойчивое «All-Flash» (то есть — только из SSD, без жестких дисков, хотя это и не принципиально) хранилище для нужд кластера vSphere, в несколько раз дешевле брендовых аналогов и с очень неплохой производительностью. Подключаться к нему мы будем по Fibre Channel, но никто не мешает сделать iSCSI, FCoE или даже, о ужас, Infiniband.

Syncro

Как ясно из названия, основой всей этой богодельни станет достаточно уникальный на рынке продукт под названием Syncro CS от компании LSI (ныне Avago).

Что же оно такое есть и чем примечательно?

По сути, это комплект из двух обычных контроллеров LSI 9286-8e (либо 9271-8i, если нужны внутренние порты) и двух суперконденсаторов для сохранения кеш-памяти на флешку контроллера в случае потери питания. Стоимость комплекта при этом в несколько раз выше цены аналогичного комплекта без HA-функционала. Но, если сравнивать с решениями на базе DRBD, то эта разница с лихвой компенсируется отсутствием необходимости иметь двойной набор накопителей.

Но самое интересное кроется в прошивке. Благодаря ей, эти контроллеры, будучи подключенными к одной SAS-сети (например, дисковой корзине с экспандерами) устанавливают через неё связь друг с другом и работают в режиме отказоустойчивого кластера.

Для нас это интересно вот чем:

• Возможность создавать RAID-массивы, доступные сразу на двух серверах
  
• Отказоустойчивость на уровне контроллеров: при смерти одного из них (или целиком сервера) второй продолжит работать и обслуживать I/O

Попался мне недавно битый внешний жесткий диск… Ну как попался? Сам купил по дешевке.

Диск как диск: железная коробочка, внутри — USB2SATA контроллер и ноутбучный диск фирмы Samsung на 1 Тб.. По описанию продавца выходило, что глючит именно USB-контроллер. Сначала, мол, и пишет, и читает хорошо, а потом постепенно начинает тормозить и вообще отваливается. Явление для внешних дисков без дополнительного питания довольно частое, так что я ему, конечно, поверил. Ну а что — дешево же.

Итак, радостно разбираю коробочку, достаю оттуда диск и втыкаю в проверенный временем и невзгодами адаптер. Диск включился, завелся, определился, и даже подмонтировался в линуксе. На диске обнаружилась файловая система NTFS и с десяток фильмов. Нет, не про эротические приключения, а совсем даже наоборот: «Левиафаны» всякие. Казалось бы — ура! Но нет, все только начиналось.

В продолжение темы о ПО SnapProtect: Архитектура резервного копирования на системах NetApp FAS, хочу осветить функционал SnapProtect for Open Systems. Начиная с релиза SnapProtect 10.0 Service Pack 4, NetApp теперь поддерживает резервные копии с direct-attached и «сторонних» хранилищ на Data ONTAP 7-Mode SnapVault системы.

«SnapProtect for Open Systems» или коротко (SPOS), выполняет блочную инкрементальную репликацию поддерждивая ОС Windows, Linux и Solaris, а также такие приложения как Microsoft Exchange Server, Microsoft SQL Server и Oracle Database.


Cхема работы SPOS

Принципиальное отличие такой схемы от стандартного подхода NetApp к резервному копированию, заключается в том, что Snapshot'ы снимаются не на уровне хранилища (Hardware Assistant), а на уровне файловой системы (или файлового менеджера типа LVM) ОС самого хоста.

После прочтения статьи «Статистика Backblaze: какой HDD самый лучший» стало понятно, что Seagate Barracuda (ST3000DM001) лидер по числу отказов. Два диска именно этой модели на файловом сервере менее чем за полтора года вышли из строя практически одновременно.

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

В продолжение темы о ПО SnapProtect: Архитектура резервного копирования на системах NetApp FAS, эта статья посвящена новым возможностям SnapProtect. Софт SnapProtect объединяет высокоскоростные Snapshot NetApp и репликацию на ленту, для уменьшения времени простоя и потери данных. Это единая консоль управления, создания и каталогизации, управления консистентными, с точки зрения приложения, snapshot в инфраструктуре, обеспечивая жизненный цикл хранения disk-to-disk-to-tape (D2D2T).



Эта схема резервного копирования выполнена в соответствии с парадигмой резервного копирования для систем NetApp FAS: основные и резервные данные расположены на СХД, а резервные копии выполняются на основе Hardware Assistant Snapshot, взаимодействуя с приложениями создавая, таким образом, Application Consistent Backup.

Думаю не ошибусь, если предположу, что у любого пользователя периодически возникает необходимость получить доступ к какому-либо сетевому ресурсу (IP-камере, сетевому накопителю, компьютеру, холодильнику и т.п.) внутри домашней или офисной сети через Интернет. Ну и само собой этот доступ должен быть:
А) универсальный, т. е. с любого компьютера или гаджета;
Б) защищенный от несанкционированного доступа нежелательных лиц.

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

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

Многие организации используют устройства, работающие с магнитной лентой, в своей инфраструктуре резервного копирования. Магнитная лента была и остается эффективным средством для долгосрочного хранения резервных копий, позволяя реализовать правило «3-2-1» защиты данных. Именно поэтому Veeam продолжает усовершенствовать поддержку ленточных библиотек, о чем и будет мой сегодняшний рассказ.



За подробностями добро пожаловать под кат.

В этой статье я рассмотрю как архитектура SnapProtect притворяет в жизнь «парадигму резервного копирования NetApp», используя передовые технологии и преимущества систем хранения, серии FAS. ПО SnapProtect (SP) предназначенно для управления жизненным циклом резервных копий, архивацией и восстановлением данных для всей инфраструктуры, расположенной на СХД NetApp FAS. SP обеспечивает связность с приложениями, консистентность при снятии резервной копии, управление репликацией/архивацией между хранилищами, каталогизацию, восстановление данных в случае необходимости, проверку резервных копий, а также другие функции. FAS очень универсальные системы, которые могут использоваться для задач как «основной» СХД, «запасной» (DR) так и для архивации данных.

Комплекс SnapProtect состоит из следующих основных компонент:

• Сервер с SnapProtect Management Server (CommServe license), для отказоустойчивости применяется кластеризация (на уровне приложения + кластеризация БД)
• Серверы с инсталлированным MediaAgent'ами.
• Агенты iDataAgent (iDA). Устанавливаются на хосты для интеграции с ОС, файловыми системами, приложениями и другими компонентами хостовой ОС.
• SP взаимодействует с хранилищем NetApp через Oncommand Unified Manager.

Продолжая тему снапшотов, затронутую в недавней статье, сегодня я расскажу о том, как Veeam Backup & Replication помогает минимизировать влияние снапшотов на «окружающую среду».

По разным причинам иногда снапшоты становятся «незримыми» для vCenter: информация о них не выводится ни в каких отчетах и не видна нигде в UI, однако сами снапшоты живут и здравствуют на СХД. Виртуальная машина преспокойно использует такой снапшот – а вот это как раз и может привести к проблемам из-за «съедаемого» места на СХД и падения производительности. Скажем прямо, проблемы, возникшие по вине снапшота-«невидимки» – достаточно частая причина обращения в саппорт.

Чтобы узнать о методах борьбы со снапшотами (видимыми и невидимыми), смотри под кат.

В продолжение статьи о парадигме резервного копирования NetApp, хочу рассказать о недокументированной возможности преобразования «архивных копий» в «резервные» для серии FAS. Отличительной чертой СХД компании NetApp серии FAS является то, что они все унифицированы. Унифицированность не только в том, что одно устройство предоставляет доступ хостам как по блочным, так и по файловым протоколам, но и по способу применения. Системы FAS используются для виртуализации, для Data Compliance, для хранения архивных копий, для построения Disaster Recovery решений и т.д. Одна и та же СХД может выполнять сразу множество функций. Так для каждой функции не нужно держать одно «специализированное» устройство, а в случае если срочно понадобится «запасная» СХД, её всегда можно «перепрофилировать» из того что есть, к примеру из СХД для архивации данных. Благодаря этой универсальности нет необходимости переобучаться под каждую из этих задач ведь операционная система, командная строка и все принципы настройки одни и те же для всех FAS систем.

В этой статье я расскажу как построенное решение «Архивация данных на NetApp» переделать в решение «Disaster Recovery».

С точки зрения бизнеса Disaster Recovery и архивирование отличаются тем, что:

• Архивирование (SnapVault) — решение предназначено для длительного хранения и защиты данных от изменений, для последующего восстановления их туда, откуда они были скопированы (или в другое место).
• Disaster Recovery (SnapMirror) — хранение данных на резервном сайте, для переключения на него (и соответственно изменения данных), в случае катастрофы.

Поясню на примере: когда у вас есть хотя бы две СХД с настроенной репликацией SnapMirror, в такой схеме одна из них играет роль источника (primary), а вторая роль приемника (Secondary). В случае аварии, при разрыве репликации (командой break, а не просто разрыв линка), принимающая (Secondary) система переведёт реплицируемое зеркало из режима read-only в режим read-write. Т.е. это инструмент для создания решения «Переключение на запасную площадку в случае аварии» (Disaster Recovery). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.



В то время, как SnapVault предназначен для архивирования на резервную (Secondary) систему, чтобы потом из неё восстановить все данные обратно на первичную систему или вообще на третью систему. Стоит отметить, что для задач архивирования очень важно хранить данные в неизменённом состоянии все время. В данном случае вторичная система, куда складываются все архивы, может быть любой модели. Здесь логично иметь самую дешевую модель NetApp FAS с медленными и дешевыми дисками большего объема. К примеру, FAS2554 или FAS2520.

В этом посте я хотелбы рассмотреть подход к резервному копирования данных на СХД NetApp серии FAS.


Архитектура резервного копирования

WAFL

И начну я издали — со снепшотов. Технология снепшотов впервые была изобретена (и запатентирована) в 1993 году компанией NetApp, а само слово Snapshot™ является её торговой маркой. Технология снепшотирования логически проистекала из механизмов работы файловой структуры WAFL. Почему WAFL не файловая система смотрите здесь. Дело в том, что WAFL всегда пишет новые данные «в новое место» и просто переставляет указатель на содержимое новых данных в новое место, а старые данные не удаляются, эти блоки данных, на которые нет указателей, считаются высвобожденными для новых записей. Благодаря этой особенности записи, «всегда в новое место», механизм снепшотирования был легко интегрирован в WAFL, из-за чего такие снепшоты называют Redirect on Write (RoW). Подробнее про WAFL.