at_it

Сабж предыдущего сообщения подходит под очень многие ситуации в сисадминстве. И хорошо, если факап случился не у тебя.

По наводке отсюда нашел интересную информацию (ключевые моменты я выделю):


12 сентября ночью в нашем датацентре произошел серьезный сбой, при котором одна из систем хранения, которая содержала в себе изображения за последние 1.5 года вышла из строя.

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

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

Ближайщие дни будут посвящены плотному анализу и мы приложим все усилия к их восстановлению. Мы предпримем любые необходимые действия, вплоть до отправки массива на анализ производителю, находящемуся в другой стране.
...
19 сентября 09:00 Все оставшиеся хранилища переведены в режим Raid 6, гарантирующий более высокую степень защиты. Новостей от центра восстановления данных пока нет.

Источник.

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

К сожалению, нашу наивность и расчет на то, что "дорогая система и работать будет хорошо и надежно" легко приводит к подобным ситуациям. Однако даже дорогая система требует внимания к обеспечению сохранности данных. Сбои случаются у любых систем. И очень важно правильно сконфигурировать систему.

Как уже рассказывал
коллега romx, raid-5 представляет достаточно опасную с т.з. надежности данных конфигурацию. Естественно, если в массиве 4 диска, то подобные соображения носят довольно умозрительный характер. Но с ростом числа дисков - что и происходит в серверах, дисковых полках и системах хранения данных, - надежность raid-5 становится неприемлемо низкой.

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

Итог: для хранения важных данных raid-5 не рекомендуется, желательно использовать raid-6 или raid-10.

Вчера таки сдохлафлешка с ESXi на одном из серверов, пришлось срочно переставлять ESXi на другую флешку.

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

Путем (сюрприз!) чтения доков на vmware.com выяснилось, что esxi требует для установки минимум на 1 Гб больше, чем есть свобоного места на установочном диске. То ли бага, то ли фича - непонятно. Соотвественно, на 4 Гб флешку ESXi также встал легко и просто.

В общем, сабж.

Возник тут вопрос: сколько iops может дать iScsi интерфейс? Один коллега утверждал, что выше 25к - никак. Я решил выяснить, так ли это, путем создания RAM-диска на Linux и раздачи его по iScsi. Клиентом выступала винда 2к3 сервер, генератором нагрузки - известный попугаеметр IOMeter. Размер диска - 4 Гб.

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

# of outstanding ios               1         4         16         64        256
Configuration     
2k, 67% reads, 100% random      2146.60   5883.74   16626.83   23025.91   23561.45
2k, 33% reads, 100% random      1915.34   5545.65   14368.89   19743.22   20903.92
8k, 67% reads, 100% random      1652.28   2581.69    5503.88   10367.98   10697.64
8k, 33% reads, 100% random      1609.63   4253.63    6143.60    8399.93    7786.10
16k, 67% reads, 100% random     1458.44   3263.05    5306.07    5682.07    5614.46
16k, 33% reads, 100% random     1352.72   2949.26    4032.43    4249.29    4621.71
1k, 67% reads, 100% random                                                24969.60

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

Также помешала глючная гигабитная карта Attansic, встроенная в плату клиента. Отдельной машины под Linux не нашлось, запустил сервер под ESXi. Правда, остальные ВМ я остановил, так что результат должен быть близок к результатам обычной железки.

Вывод: iScsi в несильно нагруженной обстановке использовать вполне можно. Теоретически, iScsi прокачает нагрузку для примерно 8-10 дисков SAS 10k.

...а все равно дураком помрешь.

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

И было непонятно, почему производительность какой-нибудь базки даже на самом современном SATA-диске, с пропускной способностью мегабайт 70 в секунду, мягко говоря, не лучшая - не сравнить с паршивеньким сервером 5-летней давности? И это при том, что доступ к ней явно ограничен гигабитным интерфейсом?

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

IOPS - это количество операций ввода-вывода в секунду. Причем, в силу особенностей механики жестких дисков, даже на сравнительно мелких объемах это количество жестко лимитировано "сверху" какой-то парой сотен (и то - для SCSI дисков, у SATA - меньше). Хорошая новость состоит в том, что увеличение дисков в рейде позволяет нарастить количество иопсов, причем зачастую - почти линейно. Но вот во всех системах, с которыми ранее приходилось работать, количество дисков ограничено достаточно небольшим числом (6, 8, в максимуме - 16). Наращивание же количества дисков - задача не простая, и решается, в общем случае, достаточно недешево.

Сошлюсь на более подробное описание проблемы все там же, далее по ссылкам: IOPS vs MBps, ИОПСы и как их измерить., ну и последняя на сегодня запись О “дешевизне” SATA-дисков Доступно, понятно.

To be continued...

С того момента, как я погрузился в мир бесплатной виртуализации на VMware ESXi, мне не давал покоя один вопрос: как незадорого получить высокую надежность для системы хранения данных?

Ответ на этот вопрос я ищу до сих пор. "Дорогое" решение понятно: взять NetApp FAS 2020 и не мучиться. Если, конечно, не смущают цены порядка 2000 долларов за терабайтный SATA-шный диск, не говоря уж про контроллеры, HBA и т.п.

Следующая мысль: взять приличный сервер под disk storage, типа 12 корзин, дополнительный БП и т.п. Но подобный сервер тоже влетит в копеечку, но главное: он не полностью redundant: материнская плата и контроллер-то у него как были 1 шт, так и останутся. То есть неплохой вариант, но все же, есть ли вариант лучше?

В последний месяц с некоторым перерывом тестирую продукт Openfiler. В нем есть поддержка DRBD - как метко замечают авторы, "сетевого raid-1". Уже лучше, практически идеально. Но есть вариант еще интереснее!

Openfiler, как и положено Linux'у, содержит не только iSCSI target, но и iSCSI-initiator (Open-iscsi). Ничто (кроме криворукости разработчиков дистрибутива и админа) не мешает подключить несколько iscsi-targets как блочные устройства и собрать из них рейд любой потребной конфигурации, например, raid-6 + spare. Как нетрудно догадаться, каждое такое блочное устройство и будет тем, что указано в заголовке, а управляющий ими компьютер (или ВМ) - контроллером.

Плюсы данного решения вполне очевидны: низкая стоимость каждого блока, практически полный плаг-и-плей, возможность использовать любой iscsi-target (linux, free bsd, windows+starwind). Недостаток очевиден: до гибкости настоящей СХД достаточно далеко, да и места все это удовольствие займет порядочно. Но, возможно, с падением цен на неттопы и корпуса к ним, а также с развитием средств управления удобство такого решения будет расти.

(Погружаясь в воспоминания)

Давным-давно, когда в природе еще не было Delphi, программировал я на Паскале. Эхх, какие были времена!!! Правда, с тех пор я сменил основное амплуа, и никаких других языков так и не выучил.

(Выгружаясь из воспоминаний)

И вот, в процессе возни с vmWare, понадобилось мне то ли залить образ из flp-файла на дискету, то ли наоборот - не помню уже. Под рукой подходящего средства, аналогичного dd в linux, не оказалось. Накатал за полчаса свое. Так началась эта разработака. В результате дальнейшего тестирования выяснилось, что и жесткие диски (как логические, так и физические) она тоже может обрабатывать. В утилитке появился немалый смысл!

dd она называетс в честь, как уже было сказано, аналогичной линуксовой тулзы. Но функциональным аналогом ее она не является и вряд ли будет. Есть, конечно, более мощные WinImage и Acronis TrueImage, но они (только не смейтесь) далеко не бесплатные.

Так что если кому-то когда-то понадобится нечто лицензионно чистое, умеющее бэкапить и восстанавливать жесткие и гибкие диски из-под винды, и Вы не боитесь кода, написанного на Паскале - велкам!

Вчера попробовал-таки наконец поставить дома vmware server 2.0 для Windows. Домашняя конигурация примерно такая: старенький AMD (3400+, по-моему), гиг памяти, XP. Остальное не особо важно. После сноса vmware player, установки и запуска vmware server свободной памяти осталось мегов так 170.

Управление теперь осуществляется через Apache tomcat server. Заход на страницу управления происходит с обязательным именем пользователя и пароля. И то, и другое, подчеркну, обязательно. А часто лично Вы вводите на домашнюю дефолтную учетку пароль, особенно пока ребенок маленький? Вот-вот. Я, пока допер, чуть башкой об монитор биться не стал: в факах и манах про этот нюанс ничего не написано.

Заходим в интерфейс server console. Не торопясь так заходим. Настраиваем гостевую машину - по паре секунд на каждую операцию. Как выражается Гоблин, "подбешивает", причем все сильнее и сильнее. Запускаем.. нет, форматируется образ диска. Ага, запускаем... А где консоль гостя-то, итить его?

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

Конечно, умом я все понимаю: памяти мало, мультиплатформенность (а точнее, изначальная линуксовость) vmware server 2.0 тоже чего-то стоит, да и "дареному" серверу по зубам не лупят. Но как же разительно это отличается от вполне удобного server 1.0! Я уж с горя стал заглядываться на установку vmware server под linux, по советам Антона Гостева с vNotion.com. Но ярлык "Санитаров" на рабочем столе привел меня в чувство.

Не буду описывать дальнейшее: как кабанский nForce firewall не давал подключиться к веб-серверу управления гостя, как неспеша работает машинка с XP и гигом памяти с двумя запущенными гостями. В общем и целом, пока не взлетело. Может, попозже взлетит.