Решили мы в компании перейти на серьёзные рельсы, чтобы всё «как у взрослых». NAS, SAN, FibreChannel и Hyper-V. Закупили оборудование, собрали, поставили и… упёрлись в проблему.
Если кратко, то проблема в производительности дискового хранилища — она плавает и падает до очень низкой.
Если полно, то читайте далее:
Итак дано:
2 шт NAS IBM DS3512 укомплектованные 12ю дисками SAS 15k на 600Гб каждый, маркированными как IBM (в реале вроде бы произведены Seagate и предназначенными именно для этой модели NAS). Так же в каждый NAS установлено по две (2 шт) карты FibreChannel 8Gbit, на 4 порта каждая. В железяке 2 «головы», имеющих независимый доступ к дискам, и соответственно по карте FC на каждую.
2 шт SAN FibreChannel Switched Fabric IBM SAN24B-5 так же с портами на 8Gbit.
3 шт сервера IBM 3550 M4 7414-F2G. В каждый сервер установлено по FibreChannel карте производства Qlogic на 2 порта 8Gbit. Внутри тоже SAS винты.
Всё фирменное, совместимое, собранное по рекомендациям лучших собаководов и вендоров.
На NAS-ах из всех 12-и винтов собран RAID5 и презентован в SAN. На RAIDе создан 4Тб раздел (GPT, NTFS) и пара разделов поменьше.
На серверах сейчас стоит Windows 2012 Server (180-trial). Драйвера ко всем железкам самые свежие, с офф.сайта IBM.
Для простоты картины будем рассматривать один сервер, один switch, и один NAS. Всё остальное в эксперименте не учавствует.
Тест:
Берём объемный файлик, например 4-8Гб, лежащий на винте сервера. Средствами винды копируем его на раздел, который презентован с NAS-а и наблюдаем эффекты.
1) Первые 1-2-4 секунды копирование идёт со скоростью 300-800Мбайт/сек. Потом плавно или резко падает до 30-60Мбайт/сек и плавно снижается далее. Впрочем иногда успевает на полной скорости скопироваться весь файл.
2) До и после копирования возможно замирание, когда окошко копирования висит и не реагирует на мышь длительностью до 1-20 (иногда больше) секунд. Иногда этого замирания нет.
3) Во время копирования NAS интенсивно мигает лампочками винтов. Когда окошко копирования «висит» — индикаторы активности дисков на NAS не мигают и не горят
4) При попытке удалить свежескопированный на NAS файл, окошко удаления замирает на 20-50 секунд, затем только удаляет файл.
5) Пробовали копировать файл лежащий на NAS на него же, но в другую папку — проблемы аналогичные.
Дисклеймер или «мы уже пробовали»:
— Подключать сервер и NAS напрямую, минуя Switch.
— Оставлять подключенным к NASу один единственный сервер по одному единственному линку.
— Делать всё тоже самое с другим NAS-ом, и другим сервером.
— Ставить Windows Server 2008 R2.
— Делать раздел на хранилище меньшего объема — 500Гб (GPT).
Спецэффекты наблюдаются всё те же.
Что это может быть? Куда смотреть, куда копать?
P/S Простите за терминологию. Мог попутать термины для обозначения железяк, но в целом картина верна.
Вышеописанное внутри виртуалки происходит?
Multipath как включен?
Кэш на запись точно включен?
Есть какаянибудь утилка от полки, IOPSы и прочее померять?
Вышеописанное внутри виртуалки происходит?
нет на сервере с подключенным луном с схд
Multipath как включен?
Вместе с утилитой IBM IBM DS Windows (x64) Storage Manager version 10.84.x5.30 идет SMIA-WinX64-10.84.x5.30 (включает Multipath с необходимыми настройками для DS3512), так что включён.
Кэш на запись точно включен?
Вот такие установки:
Enable Read Caching — Yes
Enable Write Caching — No
Есть какаянибудь утилка от полки, IOPSы и прочее померять?
Есть SANSurfer от Qlogic.
Похоже на то, что собственно момент тормоза — это и есть конец кеша на запись. Буфер запонился — началось прямое писание на диск.
P.S. не знаю как на Вашем железе и софте, у меня была такая проблема с Linux+ext4+iSCSI — именно окончание кеша на запись
Ну во первых разница в железе, софте и протоколе между Linux-ом и железкой — колоссальная. Я тоже подумал сначала что это кэш так работает. Но должно работать даже без кэша очччень быстро.
Чем очистить кэш — непонятно. Разве что выключить и включить железку снова. Но она внутри хитрая. Вполне может хранить список самых часто запрашиваемых блоков и после загрузки снова считать их в память :) Так что это будет не чистый эксперимент.
Если не ошибаюсь кэш у нее — 1Гбайт. Попробуем сейчас мелкие файлы покидать.
Когда кеш переполняется нагрузка на диски, посравнению с нагрузкой вообще без кеша в ~2 раза выше — он сохраняет закешированные данные на диск + новые порции данных.
Так же может иметь место проблема RAID5 и записи, мы когда то отошли от RAID5 в сторону RAID10.
Неужто настолько плохо все становится? Ведь это 15к SAS диски. Пусть даже RAID5 там вносит свою лепту, но неужто производительность дисков проседает до 30Мбайт/сек?
RAID5 — ru.wikipedia.org/wiki/RAID#RAID_5
проблема в том что каждая операция записи 1го сектора — это посчитать XOR и записать на 2 диска по сектору. (если RAID из 3х дисков), соответственно в 1,5 раза больше нагрузка на диски
Лучше всего посмотреть нагрузку на железку в момент перекидывания файла. Использование RAM, CPU, количество операация записи и чтения. Из этих данных можно сделать почти однозначные выводы
Ну как сказать «неплохо». Должно быть офигенно.
Потому что на СХД должны лежать образы дисков виртуальных машин, для обеспечения миграции их между серверами.
Естественно эти образы будут постоянно изменяться, и естественно нужно обеспечить им приемлимую производительность.
Обычный железный винт обеспечивает скорость записи около 100мбайт/сек. В СХД же в рэйде5 суммарная скорость должна быть… не знаю точно… но явно не меньше 100мбайт/сек.
Конечно неправильно измерять все в Мб/сек, но к сожалению в IOPS'ах я плаваю.
Если задача стоит о большом количестве паралельных записей (N виртуалок), то тестить перекидыванием большого файла бесполезно.
Мой Вам совет — разбейте рейд на более мелкие рейды (это поможет распаралелить запись), RAID5 в этом случае будет даже плюсом, т.к. с паралельной записью (в рамках одного рейда) у него всё впорядке.
Лучше проведите более реалистичный тест для Вашей ситуации — установить одну виртуалку, склонируйте её сколько нужно раз, запустите их все и понагружайте. Даже такой тест будет более реалистичен (для Вашей ситуации), чем кидание одного большого файла.
«Да, но...» (с)
Но ведь 12 очень шустрых винтов в рэйде — это огого сколько. С банальнейшей операцией линейной записи СХД такой конфигурации должен справляться не задумываясь.
А к более сложным экспериментам можно переходить лишь после успешного прохождения более простых.
Мы пробовали создать несколько виртуалок. Там тормоза внутри просто адовые.
И разбивать рэйд на несколько я не вижу смысла. Насколько я понимаю — чем больше винтов в РЭЙД5 — тем больше его надёжность.
>>. Насколько я понимаю — чем больше винтов в РЭЙД5 — тем больше его надёжность.
Ууу…
Надежность RAID-5 — ровно один диск, как только он сдох, при сдыхании следующего — массив будет потерян.
Не, можно надеяться что второй диск будет далеко от первого и можно будет отресториться, но с тем же успехом можно надеяться на прилёт волшебника на голубом вертолёте.
Вариант 1. По моим представлениям кэш на запись обычно бывает не включен (Enable Write Caching — No) в случае, если отсутствует резервирование кэш-памяти. Т.е. если у контроллера нет возможности сохранить содержимое кэша в случае пропадания внешнего электропитания. Насколько мне известно, в ходу сейчас две технологии резервирования кэша: с использованием резервной флеш-памяти (например, HP FBWC) и с использованием резервного источника питания для микросхем кэш-памяти контроллера (т.н. Battery Backup Unit, BBU). Поэтому я думаю, что есть смысл разобраться с вашим контроллером и при необходимости докупить к нему «батарейку» BBU. В любом случае включение кэша на запись станет большим плюсом к производительности.
Вариант 2. Недавно боролся с подобной проблемой. Виноват оказался не кэш, а антивирус, установленный на сервере (Symantec Endpoint Protection 11). Снос антивируса (с последующей заменой на другой) проблему решил полностью.
Вариант 1. Включил Enable Write Caching — тестирую
Вариант 2. Сервер с чистой системой установлены только драйвера, тестировалась на 3х серверах, ОС WinServ2012 и WinServ2008 R2
Кэш на запись в DSХХХХ кстати отключается если BBU по мнению системы подохла.
Если прошивка старая — то система ориентируется на дату выпуска этой батарейки.
В более свежих прошивках — система смотрит на емкость после разряда/заряда
Первые 1-2-4 секунды копирование идёт со скоростью 300-800Мбайт/сек.
файл тупо в кеш идёт
Потом плавно или резко падает до 30-60Мбайт/сек и плавно снижается далее
кеш кончился, пишем на реальной скорости.
Для проверки:
переведите все адаптеры на 4Гбит, при необходимости до 2Гбит;
тестируйте без MPIO, полку напрямую в HBA;
вырубите кеш на полке;
для проверки создайте рейд-0 на все диски;
проверяйте, в таких условиях вы должны получать достаточную скорость и для потоковой записи, и для случайной.
И ещё, рейд-10 — это два (три, четыре) рейд-1 объединённых в рейд-0. На IBMовских полках он так и создаётся.
Так же не забудьте, что в каждой полке вам нужен, как минимум, один global spare диск, чтобы не потерять массив если замена будет ехать слишком долго.
Так же не забудьте, что в каждой полке вам нужен, как минимум, один global spare диск, чтобы не потерять массив если замена будет ехать слишком долго.
В DS3512 нет, или я не нашел, что либо свяанное с spare дисками. В нутри хранилища только предлогается создать массив (RAID), можно указать только из скольки дисков будет массив, на оставшишся дисках (не включенные в созданный массив) можно содать либо новый массив либо присоединить к ранее созданному. Ни каких вариаций на тему spare я не обнаружил
В общем все это не приблизило нас к ответу. Скорость должна быть хорошая и без всяких там кэшей.
Официальный ответ от IBM — обновляйте прошивки всего, чего только можете. Только вот незадача — мы их и так уже везде обновили.
Ну занимался мой товарищ по ИТ-отделу. И в целом историю можно считать неоконченной. Производительность улучшить удалось, но что конкретно привело к этим действиям достоверно неизвестно. Мы даже обращались за помощью в IBM, но их ответ в итоге можно свести к фразе «платите деньги — мы расскажем чего и как». И это несмотря на купленную поддержку… видать мы купили какую-то поддержку очень начального уровня, а нужна очень продвинутого.
Конкретные вещи, которые помогли:
— установка на хост-машину дров от IBM только для HBA-адаптеров
— оставление драйвера MPIO от Майкрософта. Хотя есть и IBM-овские, но с ним хуже.
А вся прочая чёрная магия, вроде изменения очереди записи/чтения и еще каких-то хитрых настроек — давала лишь кратковременные нестабильные эффекты.
Простой
Средний
Средний
Простой
