Рубрика «raid» - 4

в 14:35, , рубрики: casperjs, consistency, dell, javascript, open source, perc, phantomjs, puncture, raid, системное администрирование

Привет, %хабрачитатель%!

Несколько месяцев назад у нас возникли проблемы с одной виртуальной машиной, запущенной на сервере Dell PowerEdge R720 с ESXi 5.5. Перезагрузка этой VM длилась довольно долго и вызвала сильное падение производительности на самом хосте.
Lifecycle-лог на сервере был наполнен сообщениями вида:

PDR47
A block on Disk 0 in Backplane 1 of Integrated RAID Controller 1 was
punctured by the controller.

PDR64
An unrecoverable disk media error occurred on Disk 0 in Backplane 1 of
Integrated RAID Controller 1.

Гугление привело к неутешительному выводу: рейд-массив поврежден и восстановить его невозможно. А именно — повредились данные, относящиеся к одному блоку (страйпу), сразу на нескольких дисках (double fault):
Автоматизация проверки на целостность рейд-массива на сервере Dell - 1
К счастью, делловские RAID-контроллеры обладают фичей продолжать работу, несмотря на неконсисентное состояние массива — puncture (https://www.dell.com/support/Article/us/en/04/438291/EN#Unique-Hyphenated-Issue-Here-2), что позволяет сохранить хотя бы ту часть данных, которая не повредились. Это, конечно, не никак отменяет необходимость последующей замены дисков и пересборки рейд-массива «с нуля».
Для предотвращения подобных ситуаций Dell рекомендует запускать проверку целостности массива не реже одного раза в месяц. Увы, но мы об этом узнали слишком поздно.

Такую проверку можно запускать как через веб-интерфейс Dell OpenManage Server Administrator (http://www.dell.com/support/contents/us/en/19/article/Product-Support/Self-support-Knowledgebase/enterprise-resource-center/Enterprise-Tools/OMSA/), так и через утилиты omconfig/omreport, входящие в OMSA. И, если бы разработчики из Dell не «забыли» включить эти утилиты в OpenManage для ESXi, то проблем с автоматизацией бы не возникло, т.к. понятно, что ручная проверка целостности массива на каждом сервере, совершенно не IT-way. Не говоря уже о том, что интерфейс OMSA очень медленный и работать с ним удовольствие еще то.
Ребята из Dell «поработали на славу» и простым способом автоматизировать проверку (например, через открытие в cURL заранее подготовленной ссылки) невозможно, т.к. веб-интерфейс генерируется динамически и постоянные ссылки в нем отсутствуют.

Что же делать? Читать полностью »

в 16:45, , рубрики: diy или сделай сам, Dr. Tariff, performance, postgresql, raid, sql, ssd, Ubuntu, базы данных, Блог компании Dr. Tariff, Железо, операционные системы, Процессоры

Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 3, заключительная) - 1

Пора провести финальные тесты и подвести итоги цикла статей. Сегодня мы рассмотрим влияние размера shared_buffers на производительность БД. Первые части можно почитать здесь и здесь.

В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.

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

в 14:13, , рубрики: diy или сделай сам, Dr. Tariff, performance, postgresql, raid, sql, ssd, Ubuntu, базы данных, Блог компании Dr. Tariff, Железо, операционные системы, Процессоры

Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 2) - 1

Итак, продолжим исследовать характеристики работы PostgreSQL на SSD и HDD дисках с целью повышения производительности системы. Первую часть можно почитать здесь.

В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.

В этот раз мы протестировали PostgreSQL на RAID-0 массиве из двух SSD дисков. RAID массив собирался с помощью mdadm. Размер страйпа (блока информации, который распределяется на все диски массива) – 512k.
Читать полностью »

в 15:30, , рубрики: diy или сделай сам, Dr. Tariff, performance, postgresql, raid, sql, ssd, Ubuntu, базы данных, Блог компании Dr. Tariff, Железо, операционные системы, Софт

Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 1) - 1

В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.

Производительности HDD диска было явно недостаточно. Размер базы должен был составить несколько сотен гигабайт, поэтому размещение ее в оперативной памяти было бы слишком дорого. SSD диск наилучшим образом подходит для этой задачи. Но одного SSD диска могло не хватить, поэтому было решено собрать RAID-0 массив из двух дисков. Пользуясь случаем мы решили провести тестирование производительности PostgreSQL на одном и двух SSD дисках.

Основные цели тестирования

1. Сравнить производительность PostgreSQL на SSD RAID-0 массиве с производительностью на одиночном SSD.
2. Изучить производительность базовых операций (SELECT и UPDATE) в зависимости от размера таблицы, количества подключений, настроек сервера и других параметров.

Тестирование проводилось в несколько итераций. По каждой части решено было написать подробную статью с отчетами:

  1. Тестирование одного SSD диска
  2. Тестирование RAID-0 массива из 2-х SSD дисков
  3. Влияние настроек сервера на производительность БД
  4. Сравнение SSD с HDD

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

в 12:21, , рубрики: intel, JBOD 2000, JBOD 2000 Family, raid, sas, sas диски, SATA диски, Storage System JBOD, trinity, Блог компании Тринити, дисковые полки, ит-инфраструктура, Тестирование IT-систем, тринити, хранение данных, метки: ,

Буквально недавно мне довелось тестировать дисковую полку от компании Intel®. «Казалось бы, чего может быть удивительного в обычной дисковой полке,»-подумал я, но после детального рассмотрения полка оказалась не совсем типичной. Собственно, об этом я и расскажу.

Тестирование полки Intel® Storage System JBOD 2000 Family - 1

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

в 6:02, , рубрики: raid, Блог компании КРОК, ит-инфраструктура, ОС, русская ОС, русская работающая ОС, Серверное администрирование, система хранения данных, системное администрирование, скачать без SMS, СХД, хранение данных

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

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

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

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

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

в 9:27, , рубрики: hdd, raid, ит-инфраструктура, хранение данных

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

в 16:58, , рубрики: IOPS, raid, ssd, trim, Серверное администрирование, системное администрирование, хранение данных

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

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

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

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

Почему по мере заполнения SSD падает скорость записи в RAID
Читать полностью »

в 11:48, , рубрики: CDN, LSI, raid, raid0, ssd, ucdn, webzilla, Блог компании Webzilla, Железо, системное администрирование, спасибо за чтение, СХД

Вступление

Коллеги с соседнего отдела (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/
Читать полностью »

в 12:04, , рубрики: DAS, NVR, raid, видеонаблюдение, видеорегистратор, хранение данных

Проблема с недостатком объема для хранения архива в цифровых/сетевых видеорегистраторах стара как мир. Вариантов ее решения много, но всегда есть конкретное
ограничение: «бюджет». В результате, наши желания хранить архивы по 30-60 (а это почти 30-40Тб) суток превращаются в «несбыточную мечту». В идеале хотелось бы, чтобы архив резервировался автоматически без хронической дилеммы хватит ли места очередному бэкапу на USB-HDD или нет. Наличие данной дилеммы особенно напрягает, так как процесс в долговременной перспективе может превратиться в лотерею: вы полагаете, что бекап прошел, а он и не начинался так как внешний сингловый диск давно заполнен.
Читать полностью »

1...345...7
Рейтинг@Mail.ru
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js