» HA cluster

Здравствуйте.
Уже неделю ворочаю в голове различные схемы. Прошу совета по тому, что сейчас удумал:
2 сервера выделить под хранилище данных. Со следующими тараканами в каждом:
- Воткнуть 4винта(попарно одинаковые), соответственно объединить их mdadm в raid1.
- Далее каждый raid1 засунуть в lvm, что бы потом можно было расширить добавив в lvm еще разделы md. Вот тут вопрос - мб просто поверх raid1 создать еще и raid0 с одним raid1 внутри, что бы потом можно было расширять его добавлением новых устройств??? diskN соответственно - запас для расширения на будущее.
- создать drbd устройство на основе lvm (ну или raid0, если будет сделано так).
- drbd анонсировать iscsitarget.
Создать HA кластер из 2-х proxmox серверов. Образа VM хранить на одном из iscsi дисков. Второй iscsi диск нужно подцепить к proxmox и отдать его как есть в одну из виртуалок.
Как я понимаю такого достаточно что бы обеспечить failover работу виртуальных машин?..
Набросал схемку
.

Вопросы следующие:
- Что будет с iscsi анонсированным диском если его будут юзать 2 proxmox сервера? На сколько я понял его надо будет форматировать в gfs2. С диском прокинутым во внутрь виртуалки надо видимо так же поступать?
- На сколько мощными должны быть сервера отведённые под хранилище?
- Будет ли нормально доступна расширяемость дискового пространства?

Что еще можно тут придумать/улучшить/изменить/выкинуть?

Убегаю с работы. внимательно посмотрю вночью или завтра.

zfs не рассматривается?
Таргеты можно держать в виртуалках. Девайсы или даже целый PCIe HBA с девайсами под сторадж можно прокинуть в виртуалки через RDM/PCI passtrough

LevT
Так ZFS только в соляре, еще с ней заморачиваться вариант отпадает, я её вообще не знаю. Native ZFS for Linux хз как себя ведёт, а в репах его нету, там только zfs-fuse, что явно не вариант.
Не, полноценный SAN дорого, я думал на iscsi всё сделать. Соотвесвенно и пробрасывать надо не девайс, а блочное устройство, которое open-iscsi создаст в системе при обнаружение target'а.
А вот всю инфу (диски вируалок и данные для некоторых) держать в отдельных таргетах на выделеных под это серверах.

Я не знаком с zfs, что она мне даст? Вроде как обычная ФС с встроенным LVM, по сути, или я не прав?

Не только, ZFS есть и в линуксе с недавних пор - в качестве стороннего ядерного модуля доступного в исходниках. И во фряхе с пор давних )

iSCSI это разновидность SAN.
Только бесплатно доступная )) благодаря общедоступному железу. (К 10GbE сейчас бесплатно прилагается уже и FCoE.)
Буквальная аналогия: TCP/IP точно так же всё равно, по каким L2 и физическим средам бегать.

В опенсоляре ещё и очень много было сделано в сторону бесплатной реализации транспортных SAN-сервисов (зонирование и ALUA - последнее это HA на стороне стораджа). Пока оракл всех не разогнал... Но недоделки опенсоляры доступны в реинкарнаяциях нексенты, иллюмос и смартос, можно их допилить для себя. И желательно не только для себя )))


ZFS считает чексуммы всех данных, бьет тревогу и восстанавливает порченое из избыточных копий. При невозможности восстановления - показывает отдельные погибшие файлы (что впрочем ценно в сценарии NAS и не очень в сценарии SAN).

В связи с этим с ZFS желательно не использовать дорогое оборудование, виртуализующее сторадж - а давать ей, напротив, сырые диски.

(...Мимо пробегал, на картинку пока нет возможности глянуть...)

LevT
Цитата:

(...Мимо пробегал, на картинку пока нет возможности глянуть...)

а жаль) Завтра хотелось бы на чём-то сойтись, а то мозг подпухает уже столько инфы переваривать, я так не могу, я воспринимаю только через опыт общения.

С ZFS будет много мороки по впихиванию её в ядро и проверки что всё хорошо, так что не думаю что это мой вариант. Я так и не понял какую часть схемы она заменяет...
Что iSCSI это разновидность SAN это я знаю Кстати, пустить я его хочу по 100 или 1000MbE.

Добавлено:
За ссылку на хаб спасибо, боюсь в моей ситуации будет нужен 10GbE свич, что выльется в копеечку, либо убирать второе хранилище и соединять 3 сервера чисто на 2-х головых карточках. Такой вариант не греет т.к. при отказе железяки с винтами, хана всей инфраструктуре.

Alukardd
100 мегабит категорически не советую, но гигабит в принципе сойдёт.

У меня в почту только несколько часов назад капнуло письмо от знакомого интегратора:


Цитата:

Стоимость коммутатора

Dell PowerConnect 8024F, 10GbE Managed L3 Switch, 24x SFP+ 10Gb and 4x Combo Ports of 10GBASE-T, Redundant Power Supply included in base (no spare PSU for PC8xxx), 3M SFP+ Direct Attach Twinaxial Cable Dell, 3Y ProSupport NBD warranty

на стандартных скидках составляет 6055$

Всё остальное у меня самосбор включая сторадж, а бюджет я берёг именно для этого. Брать буду.

Картинку погляжу завтра на свежую голову, извиняюсь...

LevT
К сожалению на таких девайсах мы структуру точно строить не будем, слишком дорого. Нету нужды просто в такой структуре. Я даже подумываю, что HA VM можно и не делать, а тупо оставить один сервер. Серверы хранения обязательно хочу дублировать.

Если бы был 6 или 8 портовый свитч со стоимостью где-то в $1,5-2k, то я бы попробовал выбить эти деньги с руководства.

Ах да, самый вопрос, о котором я совсем забыл упомянуть: как это всё буде жить с SATA винтами? Какие при этом варианты для дисков (много маленьких/один большой)? Виртуалок планируется пока 4 (от DC до FileServer и мало нагруженной БД)?
Или это не вариант и надо покупать SAS контроллер и диски? Не люблю RAID средствами контроллеров, mdadm нормально себя чувствует с SAS дисками? Кстати RAID который предоставляют SAS контроллеры он аппаратный или фиктивный и юзает CPU?

Да гигабитку для серверов не проблема организовать, при нехватке можно добавить в каждый сервер по сетевухе и агрегировать каналы, добравшись до 2Gb, главное свитч взять управляемый с поддержкой LAC.

Бессонница после ударного трудового будня... потому откомментирую только.

Глядя на цены свичей я морально готовился выложить похожую сумму за 8 лишь портов. Делл подфартил: он реально демпингует с этой моделью.

Интеграторы почему-то знают о 10GbE не сильно больше меня. Это я своего знакомого на тему такого делла просветил. А до того он мне безуспешно попытался продать гигабитный нетгир с 4-мя 10GbE аплинками. За 300 тысяч. У нетгира 8-портовых моделей нет точно, насчет делла я не в курсе.

Гигабитки вставные вполне достойные - двухпортовые Intel ET. 4 тыр на сегодня стоят.


Дублирование стораджа на площадке не обязательно, особеннно симметричное. Дурабилити )) стораджа достигается рейдом (или его аналогом в ZFS) внутри единственной головы. Для непрерывности бизнеса в случае маловероятного выпадения единственной хранилки целиком - соседний сервачок со свежим снапшотом, на немногих ёмких дисках. zfs send | zfs receive свежей разницы можно делать хоть ежеминутно: снапшоты в ZFS не стоят ни-че-го (в отличие от обычного LVM) Возможен офсайт бэкап для дизастер рекавери.

В опенсоляре были заделы для HA и CDP, которыми осилила воспользоваться пока только нексента в дополнительно платных плагинах.


С реальными отличиями SATA дисков от SAS - а не торгашеским FUD - можно ознакомиться в пдф-ках презентациях SNIA, на которые я ссылался в сисадминском флейме. Бояться тут нечего, по крайней мере под защитой ZFS.

Умные контроллеры - которые представляют собой проприетарную встроенную SAN - для ZFS противопоказаны ) Строго предпочтительны глупые HBA, в которые те контроллеры (но только начального уровня, те что круче не катят) превращаются отшибанием ненужных мозгов.

Да в общем-то и чипсетные каналы подходят...



Добавлено:

Сервера у меня сейчас на парных гигабитных линках, вытаскивать их не планирую: сохраню гигабитный интерконнект для подстраховки десятигигабитного (в котором единственный свич будет точкой отказа).

Для вмваре LAC на свиче не нужен: хосты вмварные умеют route portgroup traffic based on physical link load. Впрочем, я не знаю в прочих отношениях годных гигабитных свичей, где бы LAC не было.

Хорошая практика в продуктиве иметь отдельные свичи для трафика SAN и LAN. Для iSCSI надо отключать L3 фичи на свичах, или хотя бы тщательно тюнить cef, l2mtu 9000 и flow control

Впрочем, та нагрузка что Вы описываете - у меня сейчас уже есть на "действующей модели" моей инфры, с единственной циской 3750.

Думал вчера заказать вот такое за типа 7 тыр чтобы подстраховать/разгрузить/проапдейтить циску, но мне пообещали к концу недели б/у гигабитный 3Com (4094 кажется: если не удастся ему отшибить L3 фичи, придётся его отдать под LAN, а циску использовать только для SAN)



Добавлено:


Посмотрел схему.

1) Шпинделей мало: иопсы будут узким местом. Гигабитного интерконнекта точно хватит за глаза.

to be continued..

Добавлено:

В линуксовой номенклатуре девайсов и сервисов я плохо секу, gfs2 для меня тёмный лес, а про cman вообще не слышал. Если верхий прямоугольник планируется асимметричным (2+1) - то я не уверен, что drbd вытянет общую производительность=2

На мой взгляд всё переусложнено с HA на всех уровнях; посмотреть на твой успешный результат было бы интересно - но помочь его достичь я не смогу.

Про расширяемость стораджа под линуксом опять же ничего не скажу; под ZFS она есть, но страдают иопсы, пока не ZFS не сбалансирует IO по девайсам (она позиционирует это умение как своё сильное кун-фу)

Для твоих первоначальных задач четырёх шпинделей хватит за глаза - но.... скажу за себя: я начал с приобретения 16-дискового корпуса, набил его 14 терабайтниками и 2-мя SSD кэшами в конце минувшего лета и получил на выходе 6,5TB. Терабайтники и пятисотки во вторую хранилку высвободятся при переносе на этот сторадж нынешней продуктивной инфраструктуры.


Добавлено:

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

Для такого проекта начинать надо с планирования железа, а не с линуксовых сервисов, которые ты на нём уже сейчас готов городить.

LevT
Цитата:

верхий прямоугольник планируется асимметричным

в смысле ассиметричным? Параллельные ветки ни как не связаны друг с другом. А то сколько реально физических устройств лежит за той блочной абстракцией что предоставляется LVM для DRBD в качестве подопечного единого устройства его волновать не должно.

cman - это cluster manager от RH. gfs2 просто первая попавшееся мне кластерная ФС, кстати тоже от RH, (ну есть еще ocfs2, например) а как иначе организовать shared storage? Я с этимим технологиями тоже не работал. Все мои знания связаны с отдельными серверами и ethernet сетями.


В железе и особенно в теме SAN я действительно плаваю. И весьма сильно. Посему и пытаюсь понять что и как сделать. Поскольку наворочнная инфраструктура не требуется, пытаюсь понять как достичь минимальными средствами отказоустойчивость. Простой допускается даже посреди дня, но не большой скажем 1-2часа на восстановление.

Можете ткнуть на пример достойной бюджетной схд? И как будет выглядеть тогда моя схема? В сервера с гипервизорами (скорее всего это будет proxmox) надо будет воткнуть по PCI HBA карточке, что там с дровами под Linux и как ими управлять? (да-да, мы уже выяснили, что у меня тут пробел и это мой первый опыт построения SAN, хоть и крохотного)
ZFS типа подходит для shared storage? Где и как производится настройка хранилища, у них есть какой-то консольный порт или сервисный Ethernet или к ним стандартные клава с моником цепляются?

Цитата:

я начал с приобретения 16-дискового корпуса, набил его 14 терабайтниками и 2-мя SSD кэшами в конце минувшего лета и получил на выходе 6,5TB

а куда еще 1Тб делся? Я правильно понял, что это SATA диски по 1Тб?

Какова ориентировочная цена вопроса? Запросы Вы вроде как поняли. Желательно с возможностью расширения, добавить полку или даже контроллер, добавить initiator. Как я понял PCI HBA не много стоят, так что можно и видимо правильнее FC сеть делать, кстати можно ли тогда обойтись без коммутатора просто кольцом, тоже не совсем понимаю как оно устроено?

Цитата:

в смысле ассиметричным?

В том смысле, что у Вас нарисовано 2+1 девайса md. Не знаю как в линуксах, а в zfs такое возможно - но иопсов из общих физических соображений будет на уровне 1, а не на уровне 2.

Кажется, ZFS хвасталась и на этом уровне балансировать свои vdev, выдавая эту возможность за своё сильное кун-фу - но я такое не стал проверять. В любом случае избежать рабалансировки по иопсам можно только за счет разного заполнения устройств.

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

Но народ требует магии - и этому настырному требованию уступают и производители железа, и создатели файловых систем, добавляя фичи такого рода.



Цитата:

cman - это cluster manager от RH. gfs2 просто первая попавшееся мне кластерная ФС, кстати тоже от RH, (ну есть еще ocfs2, например) а как иначе организовать shared storage?

О! Спасибо! Это ещё один штришок в мою картину стораджей, которую я создавал в теме о вмваре. Впрочем, я и сам об этом додумался ночью, прежде чем уснуть.

В вмваре проприетарная кластерная ФС называется VMFS. вмварные хосты каким-то образом разруливают между собой такой сторадж и в отсутствии вцентра, но функционал LVM доступен в этом сценарии только самый минимальный. Но с прибавлением возможности оперировать общими NFS датасторами.

В вмваре общий сторадж возможен и на SAN-луне с кластерной ФС, и на NFS-шаре в LAN.

Но для HA-кластера и прочих продвинутых фич в вмваре уже требуется вцентр - аналог cman - и это техническая реальность, а не разводка на дополнительные бабки.

продолжу ещё...

Добавлено:

Цитата:

Поскольку наворочнная инфраструктура не требуется, пытаюсь понять как достичь минимальными средствами отказоустойчивость.

Если proxmox аналогично вмваре умеет держать датасторы на NFS или прочих сетевых некластерных ФС (и добавляет HA с помощью cman) - то для указанной цели не нужны ни кластерная ФС, ни SAN.



Добавлено:

Цитата:

Простой допускается даже посреди дня, но не большой скажем 1-2часа на восстановление.

Если есть 1-2 часа на восстановление - то моего например опыта с виртуализацией достаточно, чтобы совершенно обойтись без HA.

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


Добавлено:

Цитата:

Можете ткнуть на пример достойной бюджетной схд? И как будет выглядеть тогда моя схема?

не могу: я давно определился, что деньги буду тратить на многошпиндельный самосбор и максимально продвинутый интерконнект в серверной.

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

LevT
Да, proxmox поддерживает NFS storage, но разве они не тормознуты?

Цитата:

ZFS типа подходит для shared storage? Где и как производится настройка хранилища, у них есть какой-то консольный порт или сервисный Ethernet или к ним стандартные клава с моником цепляются?

Сторадж-процессор SAN может быть как проприетарным, зашитым в недра "аппаратной" СХД, так и общецелевой ОС с пакетом софтового таргета. Первый случай то же самое(!) что второй - но доступ к рукояткам управления дополнительно платный.

Если и есть в "аппаратных" СХД консольный порт - то толку от него не сильно много, потому что проприетарная CLI не даст сделать то, для чего вендор хочет продавать отдельные лицензии.

"Аппаратной" встроенной СХД являются RAID-контроллеры. Консольного порта там нет, но есть утилиты с проприетарной CLI под разные платформы и перепрошивальщики фирмваре.


ZFS умеет отдавать и файловые системы (NFS и SMB) в LAN, и блочные устройства-луны в SAN. Последнее делается с помощью платформенного пакета-таргета (в соляре это stmf, в линуксе я слышал о нескольких своих, в бсде тоже).

Функция платформенного таргета - служить нодой SAN. То есть собирать SCSI-таргеты из доступных лунов, предоставленных бэкендом. Присваивать номера логическим устройствам, рулить зонированием (SAN списки контроля доступа) и механизмами контроля доступа "физической" среды (такими, как аутентификация iSCSI инициаторов)


Добавлено:

Цитата:

NFS storage, но разве они не тормознуты?

У меня на вмваре-модели действительно раза в полтора тормознее.

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


Добавлено:

Цитата:

а куда еще 1Тб делся? Я правильно понял, что это SATA диски по 1Тб?

14 саташных терабайтников и два SSD под кэши (чтения и записи). ZFS сама управляет такого рода vdev-ами, но для жадных умеет их эмулировать на дисках. Я попробовал, мне не понравилось - и я "разорился" на SSD.

LevT
Тогда вопрос такой, нормально ли будут функционировать виртуалки с NFS шары? Ну и видимо на хранилище организовать программный raid1+0 или raid1+lvm. А рядом поставить еще одно хранилище чисто для бэкапов - с виртуалок proxmox умеет вроде снимать грамотный snapshot, ну, а доп разделы можно либо обычными методами (rsync, tar, dump), либо если применять lvm или zfs, то snapshot'ы использовать.

У меня на вмваре ) NFS сторы нормально функционируют. Но продуктивную нагрузку я на них ещё не вешал.
Насчет рейдов - извините, но после того, как я познакомился с ZFS, других рейдов для меня не существует.

Для добавления HA к зфс стораджу бсдешники написали свою утилитку синхронизации. Я бы её с удовольствием потестил, но цена обучения и освоения софтовой бсд-инфраструктуры для меня пока запретительна.

Ок. Но копаться в zfs пока не готов, особенно с учётом отсутствия оной в ядре, тот проект я не считаю, т.к. патчей пока нету даже в ванильном ядре, я уже не говорю о консервативном Debian. Так что я пока на известных мне технология mdadm и lvm посижу. Хотя с lvm тоже не общался. не было нужды.

Вроде утилитка та должна работать везде (и на соляре, и на линуксе) - но цена проекта "установить её на нексенту" для меня по-прежнему запретительна.

И... не могу её вновь найти. Всего лишь пару недель назад натыкался на неё на каком-то хостинге сорцов.

README показалось очень вкусным, проект живой и решает реальную проблему (zfs send | zfs receive - это всё таки в первооснове своей бэкап с возможностями расширения, сторадж-сервисы должны навешиваться платформенным софтом)


Добавлено:

Цитата:

Так что я пока на известных мне технология mdadm и lvm посижу. Хотя с lvm тоже не общался. не было нужды.

Прежде, чем что-то начинать делать - надо тщательно спланировать размещение уровней сторадж-сервисов. Где они будут - на стороне стораджа или на стороне хостов? На физическом железе или в гостевых машинах? LVM-кластер или SCSI-кластер? Если и тот, и другой - то ЗАЧЕМ? Где именно будут компоненты каждого из них?

Для начала тщательно инвентаризовать доступные физические ресурсы и собрать модельную инфраструктуру, чтобы понять, чего не хватает НА САМОМ ДЕЛЕ.

Потому что без опыта представления самые фантастические.


Добавлено:

ПМ посмотрите, пожалуйста.

Что скажите насчёт такой схемы?

Мой отзыв будет некомпетентным - из-за недостаточного знакомства с линуксовой софтовой инфраструктурой. Даже с NFS как таковой мой опыт ограничивается автомагическим поднятием серверов на соляре (и винде ) и цеплянием их к вмваре-клиентам.

Но софтовая инфраструктурa существует только благодаря железной. Я настойчиво советую собрать модельку на доступных физических ресурсах - и определиться со своими потребностями в закупках.

Потребностями, вызванными РЕАЛЬНОСТЬЮ физической и технической - а не фантастическими представлениями о возможностях софта и "железа" (то есть того же софта, но встроенного и проприетарного).

Узкие места настоящего железа никакой самый изощрённый софт не преодолеет.




Добавлено:

Вы рисуете логические схемы (софтовой инфраструктуры, которую собирать можно за любую сумму от бесконечности до нуля).

Нужна в первую очередь физическая схема (инфрaструктуры железной) - и вот тут уже ресурс ограничен. Мало того, потребности Ваши без действующей модели неизвестны.

LevT
Я всё же иду от обратного и считаю что это правильно. Сначала планируем что мы хотим, потом смотрим какими технологиями это можно достичь и потом смотрим во что это выливается по бюджету.
На самом деле когда вы исходите из железа вы делаете тоже самое. только отбрасывая тот или иной вариант постепенно, а я сначала пытаюсь охватить кучу вариантов, а потом остановится на одном приемлемом.

Добавлено:
Железо будет докупаться под потребности. Я даже пока хз брать ли именованные rack сервера или просто самосборными железками всё забить...

По моему убеждению, РЕАЛЬНЫЕ потребности можно прояснить только на базе собственного опыта с действующей моделью.


Добавлено:

Не исключено, что по результатам эксперимента действующая модель окажется годной для продуктива, вместе с планом закупок и последующей миграции.

Цитата:

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

Всё бы хорошо - но мы это делаем не в безвоздушном пространстве, а в контексте сложившихся представлений о возможностях технологий.
С многими из которых мы знакомы только по рекламе и ниразу не щупали, потому что считали их запретительно дорогими ("энтерпрайзными"). Это искажает картину мира и отрицательно влияет на адекватность планов там, где мы начинаем считать деньги.

Так вот: техника стремительно дешевеет, и собственный опыт стал доступен.

Пост

Получается мне есть смысл вместо NFS шары анонсировать target по iSCSI? Или всё же в моём случае профита не будет?

Добавлено:
На структуру я так понимаю это уже ни как не повлияет?..

Alukardd

Цитата:

Получается мне есть смысл вместо NFS шары анонсировать target по iSCSI? Или всё же в моём случае профита не будет?

Ну, смысл каждый определяет для себя сам. Зависит от желания лезть на амбразуру знакомиться с совершенно новой темой.

Я писал уже, что в грубой оценке специально не настраивавшийся NFS раза в полтора медленнее для вмваре, чем специально не настраивавшийся iSCSI.

Таргет анонсировать мало: за таргетом инициаторам видны луны. Особенности зрения вмваре мне в общих чертах знакомы - и привели меня к известной тебе попытке создать инструмент для зонирования лунов на том таргете, с которым я имею дело (солярном stmf).

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

LevT
Ну тогда как я понимаю, при наличии железа я смогу поиграться с iSCSI если время будет... Вдруг без проблем нак примитивном уровне заведётся...

Я до кучи еще хотел спросить про винты. Я так и не понял из той статьи на хабре, во что может вылится сбойный винт desktop серии в raid'е? Вроде ни каких проблем ни когда не испытывали... Ну что он может тупить минутами это я понял, но там еще что-то про сбой написано, но без конкретики И что рекомендуются винты с доступным SCT ERC и выставленными таймаутами в ~7сек я тоже понял.

Alukardd

на примитивном уровне iSCSI работает железобетонно. Это просто диск или диски.

Но сетевой сторадж затевается вообще-то ради масштабируемости и гибкости. И тут возникает потребность в адекватном инструменте управления жизненным циклом таких виртуальных дисков.

Иначе из этих дисков непонятного назначения грозит образоваться на сторадже свалка, аналогичная файлопомойке. Или конторе ремонтников-железячников.



Цитата:

И что рекомендуются винты с доступным SCT ERC и выставленными таймаутами в ~7сек я тоже понял.

Ну, у меня лично ничего нового по этой теме нет, после нашей переписки в скайпе.

LevT
Кажется вопрос ты мимо глаз пропустил)
Цитата:

во что может вылится сбойный винт desktop серии в raid'е?

Цитата:

ради масштабируемости и гибкости

это-то да, но вот как раз про масштабируемость я и не понял ни в контексте чистого SAN ни в контексте iSCSI...

перечитай пожалуйста нашу переписку в скайпе и переспроси, если что-то непонятно по её тексту. У меня сейчас еще меньше времени, чем было тогда.



Цитата:

это-то да, но вот как раз про масштабируемость я и не понял ни в контексте чистого SAN ни в контексте iSCSI...

Масштабируемость - дело рук самих утопающих. Для тех, кто не может или не хочет покупать платные проприетарные управлялки, остаётся единственный путь: управлять своим хозяйством скриптами.

В терминах ты продолжаешь плавать, как мне кажется. SAN это транспортная сеть SCSI: сюда относятся рантаймное (с т.зр. сети, т.е. инициатор или таргет могут упасть и перезагрузиться не потеряв сессию) резервирование кластерных лунов и мультипас между инициаторами и таргетами. У этой сети есть конфигурация (зонирование). Или её, наоборот, нет - и тогда случай негодно масштабируемый. Конфигурялка зонирования может быть более или менее удобной для админа, а часть её возможностей может быть заблокирована вендором с целью продажи опций за отдельные деньги.

iSCSI - это для SCSI разновидность даталинка. Даталинки не бывают "нечистыми" для вышележащих протоколов. За FC физику кто-то платил бешеные бабки, но это не делает её более" чистой" технологией транспорта данных по сравнению с медной парой Cat 5e.

Реальную ценность представляют проприетарные управлялки зонированием, но они же и ставят единожды купившихся в зависимое от вендора положение. И поощряют дальнейшее невежество.

Здравствуйте много Уважаемые! Помогите советом. Я тут тоже решил серверную модернизировать под 1с 8.2 Купил два сервака ibm x3650 и схд ibm ds3512. Решил не тратится пока на вмваре и поигратьсяа с proxmox. И в данный момент уперся в расшаривание луны подцепленой к сервакам двумя SAS HBA каждый. в многопутевое устройство собрал. Далее нужно включить кластер в lvm и еще немного настроек . ...

потом запустить clvmd
создать pv, volume group, lv и на созданном lv make gfs2

Так вот проблемы начинаются после создание volume group. вроде создана успешно, но vgs ее не показывает. vgscan тоже не находит. и lv в это группе создать не возможно так lvm ее не находит. зато когда пытаешься удалить pv pvremove вываливается ошибка что vg всетаки существует.... весь моск сломал уже.

вот тут на proxmox форуме эту траблу запостил там более подробно https://forum.proxmox.com/threads/11473-File-system-type-on-shared-storage-%28SAN-IBM-DS3512%29?p=62986#post62986