Хранение данных *

Введение

После тестирования и написания статьи о влиянии механизмов кэширования на производительность в младшей модели (entry level) СХД EMC VNXe3200, периодически начали чесаться руки проделать то же самое с ее старшими собратьями массивами VNX2. Недавно такая возможность представилась. Удалось прогонять тесты на VNX5400. Кроме того, помимо тестирования непосредственно VNX5400, получилось потестировать еще и решение EMC ExtremCache (PCI-E SSD карточка EMC XtremSF700 на eMLC чипах + софт EMC XtremSW). Но про EMC ExtremCache будет следующая статья. Пока же поговорим про массивы VNX2.

Казалось бы, что про диски Advanced Format за последние 4 года успели узнать все. Публикаций действительно много, но настало время рассмотреть все технические подробности и подводные камни в одной большой статье. Речь пойдёт об использовании AF-дисков в серверах, и я заметил, что для большинства администраторов даже в крупных компаниях знание предмета в большинстве случаев сводится к «это как-то связано с современными дисками, но у меня всё работает».

Многие разработчики программ для микроконтроллеров сталкивались с проблемой хранения конфигурационных данных. Это могут быть калибровочные коэффициенты измерительного алгоритма или просто последний выбранный пользователем пункт меню. Для микроконтроллера, имеющего возможность записывать в собственную flash-память, решение кажется простым — стираем сегмент и пишем туда все, что нужно. Однако, если необходимо еще и обеспечить отказоустойчивость по отношению к выключению питания в произвольный момент, задача становится нетривиальной, — по сути необходимо реализовать маленькую базу данных с механизмом обеспечения атомарности операций записи и восстановлением после сбоев. Решение этой задачи для микроконтроллеров семейства MSP430 — под катом. По количеству используемых ресурсов оно подходит даже для самых младших членов этого семейства — с размером RAM от 256 байт и falsh-памяти от 8Kb. В качестве бонуса — интерфейс командной строки (через UART) для чтения и записи конфигурации.

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

Предпосылкой к изучению данного вопроса стало наличие в сети компьютера, с вышедшем из строя дисковым накопителем. Необходимо было запустить на данном ПК «полноценную» 64-битную операционную систему Windows 7 без использования Linux-сервера, ограничившись только имеющимися в локальной сети Windows системами. Приводимые в данном посте программные продукты распространяются бесплатно и могут работать как на серверных, так и на пользовательских версиях Windows.

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

Всем доброго дня.
Так уж случилось что статьи начинают формироваться в цикл. Первая часть цикла находится здесь habrahabr.ru/post/235593
В этой части я попытаюсь упрощенно объяснить зачем нужно управлять воздушными потоками в серверной, как это реализуется, плюсы и минусы различных подходов, а так же экономическое обоснование крупными мазками.

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

Разбираемся под катом.

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

Всегда приятно, когда привычное ПО запускается с новой железкой, и нет необходимости приобретать нечто «особенное», а потом тратить время на дополнительные настройки. Коллеги из StorageReview решили проверить, насколько этот тезис применим к Veeam Backup & Replication и ExaGrid EX21000E. А мы, в свою очередь, предлагаем вам познакомиться с новым хранилищем от ExaGrid в нашем переводе. Добро пожаловать за подробностями и выводами под кат.

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

• NetApp Certified Storage Associate (NCSA)
• NetApp Certified Data Administrator (NCDA)
• NetApp Certified Implementation Engineer (NCIE)

Эта проблема наиболее актуальна для аппаратных RAID или firmware RAID (таких как Intel RST RAID 1/10/5/6) с непромышленными SSD.

Особенность SSD

SSD пишут и читают данные страницами, записать можно только на очищенные страницы, а очистить страницы можно только большими блоками. Например, у диска размер страницы 8 КБ, в блоке находится 128 страниц, таким образом, размер блока — 1024 КБ (здесь и далее, если не указано иного, КБ и МБ двоичные).

Например, если изменить 40 КБ в одном файле, то на физическом уровне это будет выглядеть так:

Проблема

Управление личными файлами на компьютере сопряжено со следующими сложностями.

• Файлы теряются (куда сохранено? как названо?);
• Навигация в файловом менеджере отнимает много времени;
• Система каталогов позволяет с относительным удобством классифицировать файлы только по одному признаку.

Решение

Решение состоит в том, чтобы:

• cпециальным образом именовать любой сохраняемый файл;
• хранить все файлы в одной папке;
• обращаться к файлам через единственный интерфейс — строку поиска (например, Spotlight в OS X).

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

Добрый день,

12-го сентября 2011 года Bitcasa анонсировали зашифрованный «Infinite Drive/бесконечный диск» облачного хранилища за 10$ в месяц после окончания бета тестирования. В прошлом году, 19-го ноября 2013-го, Bitcasa объявила, что компания меняет план бесконечного хранилища с 99$/год на 999$/год, но разрешает существующим пользователям остаться при цене в 99$/год (не распространялось на Linux клиентов в будущем).

22 октября этого года Bitcasa сообщила, что с данного момента план бесконечного диска упраздняется.

Перевод с FAQ станицы Bitcasa:

В будущем Bitcasa больше не будет предлагать и поддерживать подписку на «бесконечный» план. Существующие пользователи Bitcasa должны выбрать новый план с подходящим для них объемом данных. Чтобы удовлетворить желания пользователей кому требуется больше чем 5TB места мы изменили лимит объема данных для Pro площадки с 5TB до 10TB. Цена за PRO план будет повышена с 49$ до 99$/месяц для новых клиентов. Эти изменения не коснутся существующих клиентов.

После раздачи паков студентам Github’ом решил использовать 100 баксов в Digitalocean со смыслом, а точнее в качестве облачного хранилища — качалки всяких мелочей. Памяти, конечно, в дроплетах не так уж и много, (20 — 40 гБ в бюджетных вариантах), но они на то и мелочи, что весят немного. В качестве образа был выбран привычный Ubuntu 14.04 x32, в качестве качалки был избран transmission с его удобной веб-мордой, а как способ шаринга данных был взят apache2 с webdav. Получился Яндекс.Диск на стероидах (ssd, торрент, качающий напрямую в диск, возможности настроить больше плюшек), но с меньшим объемом жесткого диска.

В конце августа я описал в статье бюджетное решение расширения архива для NVR/DVR, но недавно ко мне в руки попал Zyxel Keenetic и еще один 5-ти дисковый DAS CFI-B8253JDGG. Существует масса разных реализаций раздачи «сетевых шар» в локальной сети, но удалось получить, что-то средне-бюджетное и защищенное.

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



Закон вступает в силу 1 сентября 2016 года. И вот интересные моменты.

Введение

Недавно и не надолго ко мне в руки попала система хранения данных (СХД) VNXe3200, которая была анонсирована компанией EMC² для заказчиков 5 мая 2014 года. VNXe3200 — это второе поколение entry-level Unified СХД компании EMC². В данной модели появились технологии доступные ранее только на более старших и более дорогих midrange массивах. В частности технология FastCachе — т.е. кэш второго уровня на SSD дисках, который встает в разрез между традиционным кэшем в оперативной памяти контроллера СХД (в терминологии EMC — Storage Processor) и собственно дисками. Я решил проверить, как данная технология влияет на производительность ввода/вывода на самых младших СХД компании EMC².

Предыстория

Когда два года назад мы выпускали Veeam Backup & Replication 6.0, одним из самых важных нововведений была масштабируемость: благодаря распределенной архитектуре на базе специально выделенных «прокси-серверов» (серверов, которые непосредственно выполняют задания резервного копирования по перемещению данных) и распределению нагрузки между ними, продукт получил возможность обслуживать инфраструктуры практически любых размеров.

Причин для создания новой архитектуры было несколько, и, соответственно, ею решалось сразу несколько задач:

1. Обеспечить масштабируемость до инфраструктур любых размеров — для этого можно создать нужное количество “прокси-серверов” (серверов, которые выполняют задания резервного копирования), между которыми можно оптимально распределять рабочую нагрузку.
2. Повысить надёжность процесса резервного копирования и исключить проблему «единой точки отказа». Даже если один прокси-сервер упадет, задачу за него завершит другой.
3. Уменьшить нагрузку, которую операции резервного копирования оказывают на производственную инфраструктуру – благодаря использованию описанного в настоящей статье механизма.
4. Снять головную боль «Как же оптимально составить расписание для нескольких заданий?» – теперь можно настроить их параллельное выполнение.
5. Автоматически следить за свободным местом на хранилище и заблаговременно предупреждать о приближении порогового значения

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

Уже несколько лет как появилась возможность любому смертному желающему арендовать не только shared-хостинг, но и «полноценный» сервер с root-доступом и возможностью настроить его так, как хочется самому. Настроить, например, кроме web-сервера еще и кучу других сервисов.
Так же поступил и я несколько лет назад. Сначала арендовал один сервер, потом другой, и переносил настройки ручками, находя нужные файлы в директории /etc.

За пару лет на моём сервере осело несколько блогов друзей, и даже почтовый сервер, так как давно не хочу, чтобы моя почта была у Google. Насчет сохранности данных задумывался после каждой статьи на Хабре, но всё было как-то не до этого. И, как говорится, админы делятся на три категории: на тех, кто не делает бэкапы, на тех, кто уже делает и на тех, кто даже проверяет восстанавливаемость из бэкапов. Так получилось и со мной, хоть хостер и очень хороший, но произошла у них авария с жесткими дисками. Да такая, что неделю они пытались восстановить диски и предварительные оценки были очень неутешительными. А бэкапов у меня не было. Какое настроение у меня было в те дни можете сами представить.

Но через несколько дней техникам хостера удалось-таки восстановить данные и запустить все виртуальные сервера на той ноде. А я задумался о бэкапах. Думал я так — бэкап должен быть не на том же сервере (естественно!), желательно, чтобы он был у меня на компьютере, но не в одном экземпляре. Я обдумал и установку FTP на домашний компьютер и даже отправку архивов письмами, но все эти варианты меня не устраивали. И я понял, что надо попробовать Dropbox, которым я к тому времени пользовался уже пару лет, а бесплатных гигов у меня было около 18-ти.

Преимущества бэкапа в Dropbox:

• Независимость от домашней инфраструктуры и канала в Интернет
• Множественные копии (сразу на все синхронизируемые ПК)
• Кроме собственного хранения бэкапы хранятся и в облаке

Что делает представленный мной скрипт?

• Инкрементальный бэкап файлов в указанных папках (по первым и пятнадцатым числам идет полный бэкап)
• Бэкап всей базы MySQL
• Бэкап архивируется с помощью 7zip, с указанием пароля (вам же не надо хранить пароли в открытом виде в Dropbox'е?)

На написание этой публикации меня подвигли 4 вещи:
1. Публикация «Почему важно поддерживать температурный режим в серверной. Как обычно устроено охлаждение серверной», в которой автор попытался выполнить почетную и очень трудную миссию по разъяснению необходимости охлаждать сервера.
2. Ошибки, вычитанные в этом посте.
3. Собственный опыт.
4. Стремящееся к нулю количество содержательных статей по тематике инфраструктуры ЦОД (я подразумеваю, что серверная = маленький ЦОД) на Хабре. Хотя «Билайн» и ребята из «ЦОДы.рф» в этом плане большие молодцы.

Итак, о чем будет этот публикация.

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

Эти два протокола долго жили в разных нишах применения, но наступило время, когда они стали конкурировать друг с другом. Мы однозначно видим, что Ethernet набирает скорость в прямом смысле слова и начинает лезть туда, где FC всегда считался единственным игроком на поле. Появились альтернативы FC, работающие на Ethernet, как в блочном доступе: IP-SAN, FCoE так и других типах, это файловый (SMB, NFS), RDMA и объектный.
Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.


* по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.

Для небольших компаний нередко применение всего двух-четырех серверов с виртуализацией, два Ethernet свитча порой даже с возможностью стекирования и Multi-chassis EtherChannel плюс СХД младшей серии — это вполне стандартная конфигурация инфраструктуры среднего бизнеса.
Таким предприятиям очень важно максимально задействовать все доступные технологии, чтобы максимально утилизировать своё оборудование и в этой статье пойдёт речь как этого добиться.

В большинстве современных серверов на борту как правило присутствует минимум два 1Gb интерфейса под данные и один 100Mb для менеджмента.

На СХД младшей серии NetApp FAS2240/FAS2220 на борту каждого контроллера помимо прочего присутствует 4х 1Gb порта.
Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC как у свитчей компании Cisco серии Nexus, в таком случае вместо интерлинков просто будет использован стек свичей. Да и вообще сервера и свитчи в такой схеме могут быть любого производителя. А если совсем всё туго с бюджетом, то можно использовать прямое включение в сервера, так если у сервера 2 порта на борту, можно будет подключить 4-ре сервера, а когда нужно будет добавить 5-й сервер, тут уж прийдётся покупать свитчи.


Схема подключения FlexPod Express.