Рубрика «СХД» - 12

В продолжение статьи о парадигме резервного копирования 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). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.

7-Mode: Недокументированные возможности или делаем DR из SnapVault - 1

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

source: http://searchsoa.techtarget.com/photostory/2240203721/Five-potential-big-data-problems-and-solutions/5/Velocity-Catch-it-Capture-fast-moving-data-and-use-it

Источник изображения

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

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

Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных - 1

В конце 2008 года на тогда ещё небольшую петербуржскую компанию вышел один западный медиахолдинг примерно так:
— Это вы там упоролись по хардкору и приспособили SSE-инструкции для реализации кода Рида-Соломона?
— Да, только мы не…
— Да мне пофиг. Хотите заказ?

Проблема была в том, что видеомонтаж требовал адовой производительности, и тогда использовались RAID-5 массивы. Чем больше дисков в RAID-5 — тем выше была вероятность отказа прямо во время монтажа (для 12 дисков — 6%, а для 36 дисков — уже 17-18%). Дроп диска при монтаже недопустим: даже если диск падает в хайэндовой СХД, скорость резко деградирует. Медиахолдигу надоело с криком биться головой о стену каждый раз, и поэтому кто-то посоветовал им сумрачного русского гения.

Много позже, когда наши соотечественники подросли, возникла вторая интересная задача — Silent Data Corruption. Это такой тип ошибок хранения, когда на блине одновременно меняется и бит в основных данных, и контрольный бит. Если речь о видео или фотографии — в целом, никто даже не заметит. А если речь про медицинские данные, то это становится диагностической проблемой. Так появился специальный продукт под этот рынок.

Ниже — история того, что они делали, немного математики и результат — ОС для highload-СХД. Серьёзно, первая русская ОС, доведённая до ума и выпущенная. Хоть и для СХД. Читать полностью »

Обзор системы хранения резервных копий ExaGrid EX21000E — тест с Veeam Backup & Replication

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

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

Уважаемые коллеги!

Теперь на портале Microsoft Virtual Academy доступен курс по материалом Jump Start 7 октября: Модернизация ИТ-инфраструктуры компании с помощью Windows Server 2012 R2. В этом курсе вы не только познакомитесь с новыми интересными возможностями Windows Server 2012 R2, но и узнаете, почему начинать миграцию с Windows Server 2003 и 2003 R2 нужно уже сейчас. Подробное описание под катом.

Опубликованы материалы Jump Start 7 октября: Модернизация ИТ инфраструктуры компании с помощью Windows Server 2012 R2

Читать полностью »

imageПроект любой сложности, как ни крути, сталкивается с задачей хранения данных. Таким хранилищем могут быть разные системы: Block storage, File storage, Object storage и Key-value storage. В любом вменяемом проекте перед покупкой того или иного storage-решения проводятся тесты для проверки определённых параметров в определённых условиях. Вспомнив, сколько хороших, сделанных правильно растущими руками проектов прокололись на том, что забыли про масштабируемость, мы решили разобраться:

  • Какие характеристики Block storage и File storage нужно учитывать, если хотите, чтобы при росте проекта система хранения выросла вслед за ним
  • Почему отказоустойчивость на software уровне надежнее и дешевле, чем на hardware уровне
  • Как правильно проводить тестирование, чтобы сравнивать «яблоки с яблоками»
  • Как получить на порядок больше/меньше IOPS, поменяв всего один параметр

В процессе тестирования мы применяли RAID–системы и распределенную систему хранения данных Parallels Cloud Storage (PStorage). PStorage входит в продукт Parallels Cloud Server.
Читать полностью »

Уважаемые коллеги!

Предлагаем вашему вниманию онлайн мероприятие, посвященное вопросам модернизации ИТ-инфраструктуры организации с помощью Windows Server 2012 R2.

Jump start 7 октября. Модернизация ИТ инфраструктуры компании с помощью Windows Server 2012 R2
Читать полностью »

Вступление

Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:
SSD + raid0 — не всё так просто
По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.

Я начал изучать проблему. Первичный диагноз был простой — аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.

После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют 'mdadm' по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS'ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).

Ситуация для меня была необычной — я никогда не гонялся за чистым bandwidth рейдов. IOPS'ы — наше всё. А тут — надо многомногомного в секунду и побольше.

Адские графики

Я начал с определения baseline, то есть производительности единичного диска. Делал я это, скорее, для очистки совести.

Вот график линейного чтения с одной SSD.

SSD + raid0 — не всё так просто

Увидев результат я реально взвился. Потому что это очень сильно напоминало ухищрения, на которые идут производители дешёвых USB-флешек. Они помещают быструю память в районы размещения FAT (таблицы) в FAT32 (файловой системе) и более медленную — в район хранения данных. Это позволяет чуть-чуть выиграть по производительности при работе с мелкими операциями с метаданными, при этом предполагая, что пользователи, копирующие большие файлы во-первых готовы подождать, а во вторых сами операции будут происходить крупными блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584/
Читать полностью »

Новая жизнь старой СХД — волшебное железо Violin для ускорения массивов

Если у вас стоят такие СХД, как EMC Clariion, VNX, VMAX, Symmetrix DMX3, DMX4, AMS 2000, HUS и другие подобные, и вам не хватает их производительности, у меня хорошая новость.

Новую быструю СХД покупать, возможно, не надо. Если вам достаточно ускорить задачи чтения, есть решение куда дешевле апгрейда массива и проще по внедрению, чем диски в Symmetix. Называется Violin Maestro.

Это аппаратный кэш на чтение, который подключается между хостом и СХД. Железка уже протестирована и уже в России. Её можно брать и ставить без какого-либо простоя и остановок. Читать полностью »

В ходе тестирований производительности ведущих флеш-систем мы, в какой то момент, задались вопросами: Каково же влияние файловой системы на производительность реальной СХД? Насколько оно существенно и от чего зависит?

Известно, что файловая система является инфраструктурным программным слоем, реализуемым на уровне ядра ОС (kernel space) или, что реже — на пользовательском уровне (user space). Будучи промежуточным слоем между прикладным/системным ПО и дисковым пространством, файловая система должна вносить свою паразитную нагрузку, влияющую на показатели производительности системы. Следовательно, при расчетах реальной производительности СХД следует учитывать зависимость фиксируемых параметров от реализации файловой системы и ПО, использующего данную файловую систему.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js