Совсем недавно появилась информация о том, что IBM планирует выпустить мейнфрейм-серверы под управлением Linux. Кратко об этом под катом.

По оценкам аналитиков Gartner, в 2016 году объем мирового рынка облачных сервисов вырастет на 16,5% и составит 204 млрд. долларов. Самый быстрорастущий сегмент — IaaS – 38,4% в год.

К 2019 году объем рынка IaaS составит уже 130 млрд. долларов. Данный прогноз подкрепляют все новые возможности, которые предоставляют клиентам IaaS-провайдеры.

Совсем недавно журналисты DatacenterKnowledge рассказали о запуске сети плавучих дата-центров. Удивительно, но данная технология не является новшеством — аналогичные разработки есть у Google. Теперь Nautilus Data Technologies, молодой стартап, если можно так выразиться, пытается развить это направление самостоятельно.

Китайский поисковик Baidu столкнулся с необычной проблемой, которую нельзя назвать характерной для дата-центров. Попробуем разобраться.

Согласно новостной заметке от Data Center Knowledge — профильного издания по теме ЦОД и событий из этой индустрии — SAP, немецкая компания, производитель программного обеспечения для организаций, предложила новое решение для аналитики ИТ-операций.

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

Мы уже рассказывали о дата-центре фотосервиса imgix, описывали историю поиска проблем с SSD-дисками проекта Algolia, а сегодня поговорим о модернизации дата-центра Stack Exchange.

Продолжая раскрывать тему не самых очевидных, но интересных, аспектов построения систем резервного копирования, сегодня предлагается обсудить, скажем так, конечную точку этой системы — место, куда будут сохраняться ваши бэкапы, и выяснить, почему важно со всей серьёзностью подойти к его планированию. Назвать это место можно как кому угодно — репозиторий, сторейдж, накопитель, система хранения и т.д. Но для простоты изложения остановимся на варианте «хранилище», подразумевая классический дисковый накопитель (т.е. ленты, магнитооптика и им подобные сегодня затронуты не будут).



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

Вот только проблема заключается в том, что некоторые режимы создания бэкапов предъявляют к хранилищам очень серьёзные требования по скорости чтения и/или записи, не забывая общую стабильность. А это значит, что если не учитывать их на этапе планирования, то можно в лучшем случае получить еле живую систему, а в худшем отправиться покупать новое оборудование за счёт своей премии.

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

Технологии хранения данных — отдельная тема. Не так давно мы косвенно затрагивали ее в нашем материале об управления дисковым пространством сервера.

Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

Мы в 1cloud занимаемся постоянным улучшением сервисов нашего IaaS-провайдера и много пишем об этом в блоге на Хабре.

Совсем недавно мы кратко рассказали о том, что стоит за картинками в интернете, на примере дата-цента фотохостинга imgix.

Сегодня мы продолжим эту тему и поговорим об особенностях подземных ЦОД.

В настоящее время Veeam Backup & Replication v8 поддерживает аппаратные снапшоты на хранилищах HP и NetApp. В последнее время наc часто спрашивают — «а с какими еще хранилищами будут интегрироваться продукты Veeam?» В этой статье будет рассказано про интеграцию будущей версии Veeam Availability Suite v9, которая выйдет в этом году, с системами хранения данных корпорации EMC.

Поддержка будет включать сразу две линейки дисковых массивов EMC и многочисленные варианты их конфигурации. Поддерживаются как системы EMC VNX, так и VNXe. Будет доступно восстановление с помощью Veeam Explorer for Storage Snapshots, который входит во все редакции Veeam Backup & Replication, включая Free Edition) и резервное копирование с использованием аппаратных снимков.

Ранее мы рассказывали об одном из наших кейсов, в рамках которого проект Hotels.ru воспользовался IaaS-инфраструктурой для масштабирования нагруженного веб-проекта.

Сегодня мы решили продолжить рассмотрение вопросов практического применения виртуальной инфраструктуры на примере мнений представителей российского ИТ-сектора.

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

Сегодня мы решили вновь рассказать об очередном этапе работ по совершенствованию систем нашего провайдера виртуальной инфраструктуры 1cloud.

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

/ фото Ted & Dani Percival CC

/ фото Pete Birkinshaw CC

Не так давно мы спрашивали представителей российских ИТ-компаний о том, какие данные они считают возможным доверить облачным сервисам. В результате некоторые из них пошли чуть дальше и рассказали об устройствах для бэкапа данных (например, Time Capsule). Мы решили продолжить тему и поговорить об интересных высокопроизводительных и емких устройствах хранения.

/ фото Intel Free Press CC

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

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

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

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

Кластер

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

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

Кольца

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

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


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

Вторая часть

Итак, продолжу свои редкие статьи на тему «как не платить 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

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



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

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


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

WAFL

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