Отличная статья по применению SyncroCS. Не каждый день можно встретить человека, умеющего правильно готовить SCST + Pacemaker. Несколько моментов:
1) В готовом коммерчески поддерживаемом виде такая связка реализована в Open-E (http://www.open-e.com/about-us/news/newsletters/product-information-open-e-dss-v7-with-avago-syncro-solution-users-en/)
2) >>«По причине отказоустойчивой натуры решения, LSI Syncro поддерживает только двухпортовые SAS диски.»
Не просто 2-портовые, а ещё и поддерживающие SCSI PR (т.е. не совсем древние). Я когда первый раз пробовал прототип Syncro CS, то со старыми 36ГБ Fujitsu ничего не завелось по этой причине.
3) >>«SC417E16-RJBOD1 — на 88 дисков, но там лишь одинарные экспандеры, что плохо скажется на надёжности, да и слотов расширения мало.»
Хм, я действительно не задумывался, будет ли Syncro работать через 1 экспандер. Официально вроде как нет?
Технически, думаю, возможно, просто теряем пропускную способность (входов не хватит, чтобы подключить оба порта с двух контроллеров и ещё каскадировать) и надёжность при каскадировании.
4) Я недавно считал стоимость нескольких бюджетных решений для СХД с тирингом. У меня получалось, что Infortrend 3024 обходится всего на 10% дороже Syncro CS. Обещанные 1,3 мегаиопса (с двух контроллеров) проверить не мог в своё время из-за отсутствия достаточного кол-ва SSD, но 200k получил, как и пропускную способность > 3ГБ/с. В качестве плюса помимо поддержки и всяких других фич получаем VAAI.
1 и 2. Относится не только к MSA, а к снапшотам вообще. Снапшот сам по себе не является полноценной резервной копией, т.к. зависит от исходного тома, сняли снапшот — и бэкапим его. Это лишь способ обеспечить бэкап работающего приложения. Но появляется вторая проблема — целостность данных при снятии снапшота.
Если мы просто получаем состояние тома, с которым работало некое приложение в определённый момент времени, то с большой вероятностью получим кашу — какие-то транзакции не завершились и т.п., как если бы мы просто нажали ресет перед бэкапом. Для решения этой проблемы придумали VSS (приложение узнает, что его хотят «заснапшотить», завершает все невыполненные операции и сообщает о готовности), а для автоматизации — куча разного софта, от HP Recovery Manager до всяких Symantec BE и прочих продуктов.
В VMware для этого свои механизмы, долго писать.
3. Если на vdisk есть место под snappool, то почему бы нет.
4, Vdisk'ом в определённый момент времени владеет только один контроллер. При падении этого контроллера, второй подхватит его vdisk'и (и все тома на них, конечно). При наличии правильно настроенного MPIO от хостов ничего не отвалится.
Производительность MSA 1040 составляет 29 000 IOPS, а MSA 2040 – 82 000 IOPS при произвольном чтении, а пропускная способность – 3,1 и 6,2 Гбайт/с соответственно.
Когда будете заниматься сайзингом, учитывайте, что это суммарные цифры для двух контроллеров, а дисковой группой и томами на них владеет только один из контроллеров. Т.е. если вам известно, что с определённого LUN'а вам нужно будет 60-70 тыс. IOPS, то вы их не получите.
Второй момент: с MSA2040 (и его OEM-близнецом DotHill 4004) в вашем распоряжении только два пула, по одному на контроллер.
Бояться Thin Provisioning как такового не стоит, ведь в данном случае можно просто отключить overcommit на пуле, и СХД просто не даст выйти за пределы ёмкости пула при создании томов.
Это есть в HP Store Virtual.
Конечно, на уровне хоста можно сделать RAID из томов с разных СХД, но влечёт за собой массу трудностей. В MSA2040 есть асинхронная репликация, традиционно используется для других целей — например, тот же DR через относительно медленный канал.
Зачем дома шумный, дорогой и тяжёлый ящик, к тому же не с тем функционалом? Дома обычно нужны файловый доступ с умеренной производительностью, тишина, всякие сервисы типа DLNA.
для SMB использование SAS дешевле, HP не предлагает SAS коммутаторы для раковых серверов
Мы когда-то усиленно продвигали свитчи LSI 6160, но они как-то не прижились, да и сам LSI забил на развитие: HCL не обновляется (MSA 2040 там нет, не помню, тестировал ли у нас), планы по выпуску SAS3 свитча отодвинулись.
Вначале всё получается относительно недорого и быстро, а потом приходит боль от ограничений: 1) дистанция 2) по SAS нет репликации
Есть ещё, конечно, такой костыль, как Chelsio USR-1100. Но зачем?
Мне вчера на тест как раз прибыл OEM-родственник HP MSA2040 — DotHill 4004, с 20x 147ГБ 15k HDD и 4x400GB SSD (HGST SSD400M). Посмотрю, как работает tiering и другие интересные штуки.
Я в курсе насчёт Вашего знаменитого lsi-sata-fuckup.sh, но вот как-то не срабатывает он. Пробовал год назад на каких-то SATA SSD + LSI 2308 HBA + LSISAS2X36. ЧЯДНТ? Наверное, такой серьёзный баг, всплывший 2 года назад не мог оставаться неисправленным. При такой доле на рынке SAS HBA и экспандеров ситуация «да он же просто не работает этот ваш LSI» долго актуальной быть не может.
взять linux и написать еще одну реализацию Software RAID массива
Это не так просто. Насколько я помню историю развития Avroraid (который теперь RAIDX), то цель изначально была простой — быстрая реализация RAID-стека для видеомонтажников плюс собственный FC таргет для HBA производства ATTO. Им важен QoS — никаких провалов при потере дисков и ребилде, так и просто высокая производительность. В те годы (2010-2011) производительность готовых СХД начального уровня и отдельный PCI RAID на запись в RAID-6 упиралась примерно в 1-1.3ГБ/с (контроллеры на чипе LSI 2108 до сих пор выпускаются, например).
Вначале всё это выглядело не очень: куча костылей к RHEL5, много действий в консоли, какая-то кривая надстройка к webmin, но производительность действительно была достойной.
В плане администрирования давно всё поправили. Последний раз, когда я видел RAIDX, это был Scientific Linux 6-й ветки, современная и удобная веб-морда. Дело осталось за функционалом: таргеты под другие интерфейсы, репликация и т.д.
Хорошая статья. Я долго откладывал, но в январе всё же займусь вплотную бенчмарками RAIDX vs что-нибудь, да хотя бы Adaptec 7805 + FC таргет (lio target ск. всего или Open-E). Недавно намерял на Infortrend ESDS 3000 серии (1 контроллер, 2 порта SAS2, 48 дисков SAS2 10k) 3200/2500 МиБ/с на чтение и запись соответственно при средней задержке < 10мс — просто упёрся в контроллер. На выяснение поведения при ребилде не хватило времени.
RAID5 хоть и защищает от одиночного сбоя диска, не переживет выхода из строя второго диска, пока первый синхронизируется после замены сбойнувшего.
Хорошо, когда Вы и заказчик осознаёте, что RAID ≠ backup. Небольшая ремарка: RAID — это не просто защита от полного выхода диска из строя, это защита целостности данных. Смерть RAID-5 для дисков большого объема провозгласили уже давно. Для WD Red показатель UER (уровень невосстановимых ошибок чтения) составляет 1x10-14. После потери одного диска в RAID-5 в 8x3ТБ массиве вы практически неизбежно прочитаете не то, что записали.
Ничего против Qnap, Synology и прочих настольных хранилок с софтовым RAID под Linux и веб-мордой не имею — отлично подходят для SMB, всё работает из коробки, но в некоторых случаях не хватает расширяемости и производительности. Тогда рассматриваем для бюджетных вариантов недорогой сервер на обычном железе плюс Windows Storage Server 2012 R2 или Open-E.
P.S. Использование для серьёзного тестирования ATTO benchmark, HDTune и подобного софта, IMHO, является моветоном. Освойте IOmeter и/или FIO. О последнем есть хороший пост на Хабре: habrahabr.ru/post/154235/
Для XP, Server 2003 и прочего legacy — самое то.
Дальше (≥Vista, Server 2008) удобнее, IMHO, штатные средства: sysprep /oobe /generalize в ОС, затем из WinPE захватить образ через DISM. Начиная с 7 / Server 2008R2 в образ можно драйверы и обновления добавлять. Но это всё относится только к переносу голой ОС (используем для автоматизации развёртывания и всяких там v2p). Для бэкапов DISM/imagex использовать нельзя.
Точно, HUS724040ALE640 = 512E, пока что внёс исправления. В понедельник буду уточнять у инженеров LSI. Заодно на следующую неделю запланирована проверка свежих контроллеров на предмет сообщаемых physical_block_size и optimal_io_size с 512E дисками.
Если Вас интересует ситуация на 4K-фронте, то консьюмерские диски уже давно и практически полностью перешли на 512E, изредка встречаются 4KN. В серверном сегменте обеспечению обратной совместимости уделяется больше внимания, одна из целей написания этой статьи — показать, что волна докатилась и до нас, пора всерьёз оценить последствия.
Беспокоится насчёт Advanced Format стоит пока ещё многочисленным пользователям Windows XP (их всё еще остаётся 17%, если верить статистике). Исправить проблему со смещением для уже установленных ОС могут многочисленные утилиты (пример — Paragon Paragon Alignment Tool, плюс у каждого производителя свои есть). Основная головная боль для любителей XP — BIOS/MBR vs диски >2ТБ, способов решения за последние годы появилось немало, например можно заставить 32-битную XP работать с GPT через Paragon GPT Loader.
1) В готовом коммерчески поддерживаемом виде такая связка реализована в Open-E (http://www.open-e.com/about-us/news/newsletters/product-information-open-e-dss-v7-with-avago-syncro-solution-users-en/)
2) >>«По причине отказоустойчивой натуры решения, LSI Syncro поддерживает только двухпортовые SAS диски.»
Не просто 2-портовые, а ещё и поддерживающие SCSI PR (т.е. не совсем древние). Я когда первый раз пробовал прототип Syncro CS, то со старыми 36ГБ Fujitsu ничего не завелось по этой причине.
3) >>«SC417E16-RJBOD1 — на 88 дисков, но там лишь одинарные экспандеры, что плохо скажется на надёжности, да и слотов расширения мало.»
Хм, я действительно не задумывался, будет ли Syncro работать через 1 экспандер. Официально вроде как нет?
Технически, думаю, возможно, просто теряем пропускную способность (входов не хватит, чтобы подключить оба порта с двух контроллеров и ещё каскадировать) и надёжность при каскадировании.
4) Я недавно считал стоимость нескольких бюджетных решений для СХД с тирингом. У меня получалось, что Infortrend 3024 обходится всего на 10% дороже Syncro CS. Обещанные 1,3 мегаиопса (с двух контроллеров) проверить не мог в своё время из-за отсутствия достаточного кол-ва SSD, но 200k получил, как и пропускную способность > 3ГБ/с. В качестве плюса помимо поддержки и всяких других фич получаем VAAI.
Если мы просто получаем состояние тома, с которым работало некое приложение в определённый момент времени, то с большой вероятностью получим кашу — какие-то транзакции не завершились и т.п., как если бы мы просто нажали ресет перед бэкапом. Для решения этой проблемы придумали VSS (приложение узнает, что его хотят «заснапшотить», завершает все невыполненные операции и сообщает о готовности), а для автоматизации — куча разного софта, от HP Recovery Manager до всяких Symantec BE и прочих продуктов.
В VMware для этого свои механизмы, долго писать.
3. Если на vdisk есть место под snappool, то почему бы нет.
4, Vdisk'ом в определённый момент времени владеет только один контроллер. При падении этого контроллера, второй подхватит его vdisk'и (и все тома на них, конечно). При наличии правильно настроенного MPIO от хостов ничего не отвалится.
Когда будете заниматься сайзингом, учитывайте, что это суммарные цифры для двух контроллеров, а дисковой группой и томами на них владеет только один из контроллеров. Т.е. если вам известно, что с определённого LUN'а вам нужно будет 60-70 тыс. IOPS, то вы их не получите.
Второй момент: с MSA2040 (и его OEM-близнецом DotHill 4004) в вашем распоряжении только два пула, по одному на контроллер.
Бояться Thin Provisioning как такового не стоит, ведь в данном случае можно просто отключить overcommit на пуле, и СХД просто не даст выйти за пределы ёмкости пула при создании томов.
Конечно, на уровне хоста можно сделать RAID из томов с разных СХД, но влечёт за собой массу трудностей. В MSA2040 есть асинхронная репликация, традиционно используется для других целей — например, тот же DR через относительно медленный канал.
Мы когда-то усиленно продвигали свитчи LSI 6160, но они как-то не прижились, да и сам LSI забил на развитие: HCL не обновляется (MSA 2040 там нет, не помню, тестировал ли у нас), планы по выпуску SAS3 свитча отодвинулись.
Вначале всё получается относительно недорого и быстро, а потом приходит боль от ограничений: 1) дистанция 2) по SAS нет репликации
Есть ещё, конечно, такой костыль, как Chelsio USR-1100. Но зачем?
Это не так просто. Насколько я помню историю развития Avroraid (который теперь RAIDX), то цель изначально была простой — быстрая реализация RAID-стека для видеомонтажников плюс собственный FC таргет для HBA производства ATTO. Им важен QoS — никаких провалов при потере дисков и ребилде, так и просто высокая производительность. В те годы (2010-2011) производительность готовых СХД начального уровня и отдельный PCI RAID на запись в RAID-6 упиралась примерно в 1-1.3ГБ/с (контроллеры на чипе LSI 2108 до сих пор выпускаются, например).
Вначале всё это выглядело не очень: куча костылей к RHEL5, много действий в консоли, какая-то кривая надстройка к webmin, но производительность действительно была достойной.
В плане администрирования давно всё поправили. Последний раз, когда я видел RAIDX, это был Scientific Linux 6-й ветки, современная и удобная веб-морда. Дело осталось за функционалом: таргеты под другие интерфейсы, репликация и т.д.
Хорошо, когда Вы и заказчик осознаёте, что RAID ≠ backup. Небольшая ремарка: RAID — это не просто защита от полного выхода диска из строя, это защита целостности данных. Смерть RAID-5 для дисков большого объема провозгласили уже давно. Для WD Red показатель UER (уровень невосстановимых ошибок чтения) составляет 1x10-14. После потери одного диска в RAID-5 в 8x3ТБ массиве вы практически неизбежно прочитаете не то, что записали.
Ничего против Qnap, Synology и прочих настольных хранилок с софтовым RAID под Linux и веб-мордой не имею — отлично подходят для SMB, всё работает из коробки, но в некоторых случаях не хватает расширяемости и производительности. Тогда рассматриваем для бюджетных вариантов недорогой сервер на обычном железе плюс Windows Storage Server 2012 R2 или Open-E.
P.S. Использование для серьёзного тестирования ATTO benchmark, HDTune и подобного софта, IMHO, является моветоном. Освойте IOmeter и/или FIO. О последнем есть хороший пост на Хабре: habrahabr.ru/post/154235/
Дальше (≥Vista, Server 2008) удобнее, IMHO, штатные средства: sysprep /oobe /generalize в ОС, затем из WinPE захватить образ через DISM. Начиная с 7 / Server 2008R2 в образ можно драйверы и обновления добавлять. Но это всё относится только к переносу голой ОС (используем для автоматизации развёртывания и всяких там v2p). Для бэкапов DISM/imagex использовать нельзя.
Беспокоится насчёт Advanced Format стоит пока ещё многочисленным пользователям Windows XP (их всё еще остаётся 17%, если верить статистике). Исправить проблему со смещением для уже установленных ОС могут многочисленные утилиты (пример — Paragon Paragon Alignment Tool, плюс у каждого производителя свои есть). Основная головная боль для любителей XP — BIOS/MBR vs диски >2ТБ, способов решения за последние годы появилось немало, например можно заставить 32-битную XP работать с GPT через Paragon GPT Loader.