Необходима помощь в реализации проекта СХД

[ITER]

Что значит СХД в данном контексте - одна или несколько полок дисков с полным резервированием всех компонентов: диски в бэкплейнах с двойными сас-экспандерам, подключаются к RAID-контроллерам отдельных систем (системы в отказоустойчивом кластере на базе *NIX), в каждой из которых стоит по своей IB-карточке 2-х портовой, которые ходят на 2 различных IB-рутера. Везде резервирование по питанию. Т.е. полное резервирование всех систем в комплексе. Вот для этого отказоустойчивого кластера управляющих систем и нужны (были) платформы.

А можно подробнее каким образом вы собираетесь это реализовать. Т.е. ну допустим у вас железо есть, что дальше? Какой именно софт позволяет сделать, то что вы хотите?

[Stranger03]

Нужен СХД.

СХД своими руками? То есть вы хотите своими мозгами с нашей помощью переплюнуть десятилетия испытаний целых лаборатироий таких мостров как ЕМС и Хитачи? Хм. Я конечно не сомневаюсь, что Россия богата на умищи и даже готов обсудить финансирование данного проекта. Но при условии, что через год вы и ваша фирма будете мне выплачивать проценты от реализации этого решения.

До сих пор мучаемся с HP EVA - гуано (готов обсудить отдельно, если у кого-то подозрения в прямоте рук). Смотрели EMC Clarion CX4, решение от Hitachi того же уровня - черезмерно дорого за полученную производительность и функционал, вещь сама в себе.

Пишите сюда, что вас не устроила в Еве, в Хитачи, в ЕМС. Как вы тестировали, что понравилось, что не понравилось, что хотите в итоге получить.

Что значит СХД в данном контексте - одна или несколько полок дисков с полным резервированием всех компонентов: диски в бэкплейнах с двойными сас-экспандерам, подключаются к RAID-контроллерам отдельных систем (системы в отказоустойчивом кластере на базе *NIX), в каждой из которых стоит по своей IB-карточке 2-х портовой, которые ходят на 2 различных IB-рутера. Везде резервирование по питанию. Т.е. полное резервирование всех систем в комплексе. Вот для этого отказоустойчивого кластера управляющих систем и нужны (были) платформы.

Да, коллега прав. Ну допустим есть у вас 4-е микровых кузова с кучей дисков внутри. даже допустим в каждом кузове плата, процы, память. Типа серваки. Что дальше? Как вы из этих серверов (железа) собрались делать отказоустойчивую СХД с единым управлением, резервированием всего и вся?
P.S. в ваш бюджет 90К можно вписать более чем неплохую железяку. Если только не отталкиваться от требуемых 60К иопсов. А ориентироваться на реальные потребности. Как вариант IBM SVC + DS3500.

[Serge10]

ITER

Т.е. ну допустим у вас железо есть, что дальше? Какой именно софт позволяет сделать, то что вы хотите?

Рекомендую почитать ветку форума на ixbt.com, ссылку на которую я приводил выше. Там этот вопрос обсуждался. В частности, возможны 2 варианта - установка OpenSolaris/ZFS в кластерной конфигурации (в идеале можно получить аналог СХД 7000 серии от Sun/Oracle) и установка Windows storage server. Безусловно, это не тривиальные вещи требующие инженеров соответствующей квалификации, но вполне реальные. Есть еще третий вариант - в описании продукта на сайте Supermicro имеется указание на наличие соответствующего софта у их партнеров. Не знаю, о чем идет речь, но, судя по всему, можно заказать уже готовое решение. Правда не уверен, что в этом случае его цена не сравняется/превысит цену обычных СХД.

Stranger03

СХД своими руками? То есть вы хотите своими мозгами с нашей помощью переплюнуть десятилетия испытаний целых лабораторий таких монстров как ЕМС и Хитачи?

По-моему, в этом нет ничего невозможного. Не забывайте, что второй раз идти той же дорогой гораздо проще, чем прокладывать ее . Не так давно аргументы, подобные Вашим, приводили при обсуждении любого проекта OSS . А вопрос, как Вы верно подметили, чисто экономический и, грубо говоря, сводится к выбору - что дешевле - купить готовую СХД, или разработать свою. Я уже говорил ранее, бывают ситуации (ВУЗы, НИИ) когда имеется квалифицированный персонал, работающий практически бесплатно. В этом случае создание СХД своими силами может быть рентабельно .

orfeus2006

Именно поэтому диски только SAS (только они допустимы в бэкплейнах с двойным экспандером, читай резервированием)

Мне кажется, Вы не правы, хотя глубоко я в этом вопросе не разбирался. В большинство классических СХД ставят однопортовые SATA-диски без появления SPoF.

[Stranger03]

По-моему, в этом нет ничего невозможного. Не забывайте, что второй раз идти той же дорогой гораздо проще, чем прокладывать ее . Не так давно аргументы, подобные Вашим, приводили при обсуждении любого проекта OSS . А вопрос, как Вы верно подметили, чисто экономический и, грубо говоря, сводится к выбору - что дешевле - купить готовую СХД, или разработать свою. Я уже говорил ранее, бывают ситуации (ВУЗы, НИИ) когда имеется квалифицированный персонал, работающий практически бесплатно. В этом случае создание СХД своими силами может быть рентабельно

Для Вуза, НИИ оно может и рентабельно, в плане обучения. Но продуктив на этом запускать лично я бы сильно поостерегся. Ну а на тему проторенных дорожек, то-то САН Майкросистемс выпустив 7000-ю серию "тут же раздал ее код". Создавайте братцы, кому не лень.

[orfeus2006]

Всем спасибо кто откликается - это первое.
Финансирование в целом не нужно - это второе. Я рад что все помогают по мере сил, и среди отвечающих есть люди с мышлением "почему нет?". Думаю именно подобные им люди рождали технологии, подобные CUDA и иже с ними. Люди для реализации этой задачи у нас в принципе тоже есть и есть уверенность в них.
Так вот, "кларион 2", не нужен. Не нужен тот функционал, что был рожден в годах лабораторных исследований. Примерно как смартфон с кучей наворотов, работающий 1 день без розетки.
Нужна сбалансированная архитектура с описанными приоритетами, со стандартными средствами администрирования RAID-массивов, скажем как те, что дает Adaptec. Отказоустойчивый кластер поднимается под линем - OpenSolaris/ZFS вполне подойте в том числе. И нужна чистая производительность. Мапить эти тома на MS SQL как диски - есть соответствующий софт. Т.е. нужен обычный тупой сотовый телефон, по которому можно только звонить, но делать это недели 2 без розетки. И который стоит при этом в 15 раз меньше.

Т.е. что же я хочу? Возьмем 216 супермикровский корпус с экпандерным бэкплейном, забьем его матерью с Xeon 55xx/56xx, по максимуму оперативой, Adaptec 5805 (или LSI для SAS2.0), 24хSavvio 10к3 300гб SAS (Intel X25E), IB-card. Установим на него почти любой линь. Соберем на дисках массив RAID10 из 24 дисков. А в оперативы минус нужное для линя - разметим RAMDISK. Затем эту "активную полку" подключим по финику к серверу MS SQL и примапим ему том из обычных дисков - под данные и RAMDISK - под логи. Мы получили очень высокоскоростную внешнюю полку. А вот теперь собственно вопрос - как миниммальным бюджетом зарезервировать риск вылета матери, проца, памяти, рейд-контроллера, IB, IB-шнурков? Вот собственно то решение, которое рисует воображение - это то, что нам нужно. Поскольку количество полок планируется к наращиванию - собирать все это лучше всего в отдельном кузове(ах)

Мне кажется, Вы не правы, хотя глубоко я в этом вопросе не разбирался. В большинство классических СХД ставят однопортовые SATA-диски без появления SPoF.

Что имеется ввиду? В документации к супермикровским бэкплейнам с двойным сас-экспандерам черным по белому написано, что только сас при подключении 2х контроллеров.

[Stranger03]

А вот теперь собственно вопрос - как миниммальным бюджетом зарезервировать риск вылета матери, проца, памяти, рейд-контроллера, IB, IB-шнурков? Вот собственно то решение, которое рисует воображение - это то, что нам нужно.

Взять два таких кузова, на обоих ставить опенсолярку и реплицировать по айпи кучу дисков. Для этого как минимум понадобится либо много изернет портов, чтобы по ним прокачать несколько терабайт, либо поднимать IP-over-FC. Что тоже потребует не мало портов.

Что имеется ввиду? В документации к супермикровским бэкплейнам с двойным сас-экспандерам черным по белому написано, что только сас при подключении 2х контроллеров.

двойной сас експандер не защитит вас от сбоя мат.платы.

[Serge10]

Stranger03-

Взять два таких кузова, на обоих ставить опенсолярку и реплицировать по айпи кучу дисков. Для этого как минимум понадобится либо много изернет портов, чтобы по ним прокачать несколько терабайт, либо поднимать IP-over-FC. Что тоже потребует не мало портов.

Так это все уже имеется . Мы же именно эту железку и обсуждаем...

двойной сас експандер не защитит вас от сбоя мат.платы.

С сайта Supermicro:

Robust Data Availability:
- Shared storage between redundant controllers

в том числе и с SATA-дисками.
Насколько я понимаю, проблем быть не должно, даже при вылете платы...

orfeus2006

Что имеется ввиду? В документации к супермикровским бэкплейнам с двойным сас-экспандерам черным по белому написано, что только сас при подключении 2х контроллеров.

Это верно для одного ящика. И, как справедливо отметил Stranger03, не защищает от вылете мат. платы (IMHO, гораздо более вероятное событие, чем вылет бэкплейна). Здесь же исходно предполагается кластерная конфигурация. Кто мешает Вам зеркалировать данные между двумя ящиками, входящими в систему?

[orfeus2006]

Почему не реплицировать данные дисковых массивов 2х таких железок? Ну собственно по 2-м причинам: через IB и так придется реплицировать по сути оперативу. А это ОЧЕНЬ большой поток данных. Потому и IB - QSFP 40Gbit. А второе - придется удваивать количество дисков (а это удорожение конструкции).
Кстати, а журналируемые ФС в целом оченно даже должны способствовать репликации данных на дисковых массивах

Как собственно решить эту проблему? Ну взять скажем 216 кузов, забить его дисками...и все. Далее собрать 2 системы - либо в твиновом кузове, либо в независимых кузовах - не суть важно. В каждой по 2-х портовой IB-карте с подключениями к 2-м IB-рутерам, своя мать, проц, память, контроллер (и эти 2 контроллера независимых систем в кластере, как раз таки и подключаются к 216 кузову к бэкплейну с двойным сас-экспандером напрямую - чем обеспечивается резервирование целиком всех систем). Что мы получили? То, что нужно - все резервируется. Бэкплейн автоматом переключается на текущий рабочий контроллер, а данные в системах реплицируются поднятым софтом для отказоустойчивого кластера.
В принципе, то что мы обсуждали - SYS-6036ST-6LR - действительно реализует. Только он базируется на 936 платформе. Зато делает это в одном кузове. Но и у него есть ряд минусов (терпимых, но все же) - мало шпинделей (хоть и большего размера, можно полки сверху прицепить), слабая расширяемость дополнительными рейд-контроллерами (если она вообще возможна - на сайте только 3 фотки непонятного качества, мануалов и брошюр пока нет), матери позволяют не слишком много оперативы - лишь 48Гб предел. А хотелось бы в районе 192 по пределу. Не ясен вопрос возможности IB QSFP. Но поскольку он весьма близок к нужному нам - я попросил ценник на него и сроки. До сих пор никто не ответил..

На счет противопоказанности SATA в этой модели - внимательно читаем здесь http://www.supermicro.com/products/nfo/ ... mpList.pdf, особенно помеченное внизу красным для EL2 - это как раз модели с даблсас экспандером. Никакой более новой инфы по, скажем, SAS2 моделям, я пока не видел Потому и рассуждаю исключительно на основе официальных данных с сайта супермикры.

ЗЫ Быть может, я использую неправильную терминологию и поэтому мы до сих пор никак не придем к консенсусу?

[orfeus2006]

А теперь по старому вопросу - за что я не люблю HP EVA?
Вы знаете, до момента ее покупки - я вообщем с фанатизмом и уважением относился к продукции HP, вообще принимал активное участие в заказе в том числе платформ для наших боевых MS SQL - серверов - на базе HP DL380G5. НО. В этих серверах стоят по 8 дисков (кроме системы) - 4 диска в RAID10 из SAS 15k 73Gb под логи и 4диска в RAID10 из SAS 10k 146Gb под данные. Рейд контроллер - родной плюс батарейка. Как бы ничего лишнего.
Покупка HP EVA прошла мимо меня, когда я слышал краем уха, что "к нам едет зверь, слышь - она 1гбайт/с на файловых операциях дает" - мне в целом было радостно за отпимизм коллег, но что-то посдказывало, что что-то не то. Так и вышло - приехала EVA + в результате 2 полки, забитые FC 15k. Мапим к серверам, пускаем тест sqlio - наш стандартный набор. В сравнении с локальными массивами - вроде и IOPS-ов больше и время отклика среднее на уровне или меньше, максимумы ниже, потоковая скорость - выше. НО, когда выносим на нее файл данных с сервера или логи с сервера или и то и другое вместе - возникает ПОПА. Даунгрейд относительно исходной производительности системы на 20-30% и более. КАК такое может быть - до сих пор не понимаю (только один вариант - latency на FC-канале дает такой трабл). Как массив из 24 дисков может слить массиву из 4х дисков? Да, я понимаю, что там резвервирование, а значит кэш на запись отключен. Но не может быть надежность той же производительности ТАКОЙ ДОРОГОЙ. Если интересно - в пон. публикану полные спеки и разметки EVA, но факт остается фактом - система ценой > $100к работает надежнее, безусловно, но медленнее 1-го массива из 4 SAS дисков. Хотя как это может быть - в голове не укладывается.
ЗЫ Кто захочет обсудить "кривость рук, неумение ее готовки" - строго после спеков я весь ваш, к растерзанию готов. Ибо страх получить очередную СХД с той же болячкой меня пугает больше.

[Stranger03]

А теперь по старому вопросу - за что я не люблю HP EVA?

Что-то мне подсказывает, что ХП Ева на 24-е винта ну никак не может слить 4-м внутренним винтам.

[yuri-]

Тут не раз Opensolaris/ZFS упоминался. Каким образом на ней получить высокую доступность?
Вы уверены что оно Production Ready?

[Stranger03]

Как собственно решить эту проблему? Ну взять скажем 216 кузов, забить его дисками...и все. Далее собрать 2 системы - либо в твиновом кузове, либо в независимых кузовах - не суть важно. В каждой по 2-х портовой IB-карте с подключениями к 2-м IB-рутерам, своя мать, проц, память, контроллер (и эти 2 контроллера независимых систем в кластере, как раз таки и подключаются к 216 кузову к бэкплейну с двойным сас-экспандером напрямую - чем обеспечивается резервирование целиком всех систем). Что мы получили? То, что нужно - все резервируется. Бэкплейн автоматом переключается на текущий рабочий контроллер, а данные в системах реплицируются поднятым софтом для отказоустойчивого кластера.

Э, то есть вы хотите взять пару серверов с адаптеками типа 5085, взять тот несчастный 216-й кузов (адын штука - http://www.supermicro.com/products/chas ... R900LP.cfm), эти сервера кабелями подключить к бекплейну 216-го кузова. Типа так обеспечить полное резервирование?

[ITER]

Рекомендую почитать ветку форума на ixbt.com, ссылку на которую я приводил выше. Там этот вопрос обсуждался. В частности, возможны 2 варианта - установка OpenSolaris/ZFS в кластерной конфигурации (в идеале можно получить аналог СХД 7000 серии от Sun/Oracle) и установка Windows storage server. Безусловно, это не тривиальные вещи требующие инженеров соответствующей квалификации, но вполне реальные.

А не боитесь @#$%ться в результате? Когда купите все это железо и начнете из него лепить не понятно что? Или у вас вся отвественность - "если что не так уволюсь и всего делов"

[orfeus2006]

Э, то есть вы хотите взять пару серверов с адаптеками типа 5085, взять тот несчастный 216-й кузов (адын штука - http://www.supermicro.com/products/chas ... R900LP.cfm), эти сервера кабелями подключить к бекплейну 216-го кузова. Типа так обеспечить полное резервирование?

Не обязательно 216 - в нем просто максимум 2.5 дисков в 2U и при этом есть бэкплейны EL2. Подключение между кузовами кабелями SFF8088. Что конкретно настораживает в данном решении? Какое место оголяется или является потенциально уязвимым в этом случае по вашему?

Никто не собирается увольняться. Поверьте, если бы была возможность купить удовлетворяющее текущим потребностям готовое решение за вразумительные деньги - никто не стал бы ломать голову - я люблю спать, а не моск ломать. Просто одно купленное решение уже есть - сейчас попробуем (в том числе через гуру мидренджа IXBT) разобраться с HP EVA - быть может что то даст. Но пока ситуация близка к критической.

[Stranger03]

Не обязательно 216 - в нем просто максимум 2.5 дисков в 2U и при этом есть бэкплейны EL2. Подключение между кузовами кабелями SFF8088. Что конкретно настораживает в данном решении? Какое место оголяется или является потенциально уязвимым в этом случае по вашему?

Так работать не будет.
1. вы не сможете на двух адаптеках примонтировать один и тот же лун, созданный на одном адаптеке.
2. вы не сможете юзать одновременно один лун на двух системах
3. сбой одного из серверов приведет к потере доступа к данным на луне, который привязан к нему.
Самый простой вариант: брать два равнозначных сервера, сувать туда по 4-х портовому изернету и реплицировать все на уровне ОС.