Назрел вопрос.Есть внешний дисковый массив.
У массива 2 интерфейса SCSI ( две отдельных шины ).
Через обе шины он умеет отдаватся одновременно.
То есть массив виден как стандартный SCSI-диск висящий на шине.
По двум кабелям сразу.Нужна файловая система.
Файловая система в которой предусмотрено что её будут использовать 2 сервера сразу.
Использовать на чтение-запись.То есть вопрос - какая файловая система, будучи размещённой на общем блочном устройстве, поддерживает возможность смонтировать её на RW сразу с двух хостовых компьютеров?
Вероятно более типовой случай это nbd - устройство, но суть от этого не меняется.
Надо один блочный девайс смонтировать на rw сразу на двух машинах.
Хелп ме )))
блочный девайс или файловая система?
Если блочный девайс, то нет нужды в дополнительно заморачиваться - бери и пиши с обеих машин.
Файловая система уже интересней ;) платное - например IBM GPFS (Linux, AIX) ..., бесплатное - GFS, OCFS2 ...
>блочный девайс или файловая система?
>Если блочный девайс, то нет нужды в дополнительно заморачиваться - бери и
>пиши с обеих машин.
>Файловая система уже интересней ;) платное - например IBM GPFS (Linux, AIX)
>..., бесплатное - GFS, OCFS2 ...
Извините, вы точно уверены что вы правильно меня поняли? Я долго и внимательно читал обзоры на GPFS и как я понял там нет такой возможности, чтоб с одним набором блоков работать сразу с двух машин одновременно.....вы сами это делали или руководствуетесь пресс-релизом?
Просто я поначалу тоже смотрел на GPFS а потом выяснилось что они имеют ввиду противоположное - возможность один и тот-же файл, с одним именем размазать физически между разными физическими машинами для ускорения доступа.
А мне надо типа:
На сервере 1:
mount /dev/sdb1 /mnt/shared-hard-disk -o rw -t some_fs
На сервере 2:
mount /dev/sdb1 /mnt/shared-hard-disk -o rw -t some_fs
При этом sdb - один и тот-же физический жесткий диск, подключенный сразу к двум машинам. И чтоб в /mnt/shared-hard-disk можно было писать-читать-удалять одновременно, с отслеживанием совместного доступа к файлам, блокировками и прочими вкустностями....
а GFS чем не устраивает ?
>>блочный девайс или файловая система?
>>Если блочный девайс, то нет нужды в дополнительно заморачиваться - бери и
>>пиши с обеих машин.
>>Файловая система уже интересней ;) платное - например IBM GPFS (Linux, AIX)
>>..., бесплатное - GFS, OCFS2 ...
>
>
>Извините, вы точно уверены что вы правильно меня поняли? Я долго
>и внимательно читал обзоры на GPFS и как я понял там
>нет такой возможности, чтоб с одним набором блоков работать сразу
>с двух машин одновременно.....
>
>вы сами это делали или руководствуетесь пресс-релизом?
>
>Просто я поначалу тоже смотрел на GPFS а потом выяснилось что они
>имеют ввиду противоположное - возможность один и тот-же файл, с одним
>именем размазать физически между разными физическими машинами для ускорения доступа.
>
>А мне надо типа:
>
>На сервере 1:
>
>mount /dev/sdb1 /mnt/shared-hard-disk -o rw -t some_fs
>
>На сервере 2:
>
>mount /dev/sdb1 /mnt/shared-hard-disk -o rw -t some_fs
>
>При этом sdb - один и тот-же физический жесткий диск, подключенный сразу
>к двум машинам. И чтоб в /mnt/shared-hard-disk можно было писать-читать-удалять одновременно,
>с отслеживанием совместного доступа к файлам, блокировками и прочими вкустностями....
ИМХО блокировки не возможны без поддержки со стороны "устройства". оно должно быть умным достаточно чтобы разруливать конфликты. а делать это оно может только при условии, что FS ему известна. значит надо читать доки на этот чудо-девайс. все начинается оттуда.\^P^/
>ИМХО блокировки не возможны без поддержки со стороны "устройства". оно должно быть
>умным достаточно чтобы разруливать конфликты. а делать это оно может только
>при условии, что FS ему известна. значит надо читать доки на
>этот чудо-девайс. все начинается оттуда.
>
>\^P^/Если продолжить вашу логику, то транзакции в принципе невозможны без поддержки с стороны жесткого диска :)
Зачем устройству быть "умным"?
Достаточно драйверу файловой системы быть написанным с учётом того, что он не один может работать с этим набором физических секторов.... и ноды могут как-то синхронизировать свою работу через сеть или области диска.
>>ИМХО блокировки не возможны без поддержки со стороны "устройства". оно должно быть
>>умным достаточно чтобы разруливать конфликты. а делать это оно может только
>>при условии, что FS ему известна. значит надо читать доки на
>>этот чудо-девайс. все начинается оттуда.
>>
>>\^P^/
>
>Если продолжить вашу логику, то транзакции в принципе невозможны без поддержки с
>стороны жесткого диска :)
>
>Зачем устройству быть "умным"?
>
>Достаточно драйверу файловой системы быть написанным с учётом того, что он не
>один может работать с этим набором физических секторов.... и
>ноды могут как-то синхронизировать свою работу
>через сеть
эээ... если постановка задачи это допускает, то возможно. только я плохо себе представляю драйвер ФС, который дергал бы сеть...
>или области диска.
а это уж фиг вам. реализовать это race-free возможно только в том случае, когда диск умеет выполнять чтение-модификацию-запись (или хотя бы чтение-запись) как атомарную операцию.
в SMP-системах такое обращение к памяти именуется "семафор". вся синхронизация потом сводится к ожиданию свободного состояния семафора с изменением его состояния _атомарно_ с операцией чтения, используемой для проверки занят/свободен, и работой с некоторой управляющей структурой, защищенной этой конструкцией.
у "простого" диска (ни IDE, ни SCSI) нету read-modify-write цикла "в одну шинную транзакцию". (а даже если у какого уникального есть, то прежде чем ФС сможет воспользоваться оной потребуется поддержка этой операции драйвером диска)
мне складывается впечатление что два шлейфа у железки есть для реализации multipath, а не для того, чтобы два сервера цеплять. так что читайте доку на железо. и не пытайтесь заставить эту байду работать по вашему сценарию если она для этого не предназначена.\^P^/
>>
>>Достаточно драйверу файловой системы быть написанным с учётом того, что он не
>>один может работать с этим набором физических секторов.... и
>>ноды могут как-то синхронизировать свою работу
>>через сеть
>эээ... если постановка задачи это допускает, то возможно. только я плохо себе
>представляю драйвер ФС, который дергал бы сеть...
>>или области диска.
>а это уж фиг вам. реализовать это race-free возможно только в том
>случае, когда диск умеет выполнять чтение-модификацию-запись (или хотя бы чтение-запись) как
>атомарную операцию.Я к сожалению никогда не внедрял такое решение, но отчётливо помню что ещё в Windows NT 3.51 одно из первых виндовых кластерных решений базировалось именно на жестком диске, физически подключенном одновременно к всем узлам кластера. Он так же именовался ресурсом кворума.
Насчёт семафоров - у вас просто не хватает фантазии)))) Вон езернет работает ведь без всяких семафоров))) ( классический, с коллизиями :-)
>>>Достаточно драйверу файловой системы быть написанным с учётом того, что он не
>>>один может работать с этим набором физических секторов.... и
>>>ноды могут как-то синхронизировать свою работу
>>>через сеть
>>эээ... если постановка задачи это допускает, то возможно. только я плохо себе
>>представляю драйвер ФС, который дергал бы сеть...
>>>или области диска.
>>а это уж фиг вам. реализовать это race-free возможно только в том
>>случае, когда диск умеет выполнять чтение-модификацию-запись (или хотя бы чтение-запись) как
>>атомарную операцию.
>
>Я к сожалению никогда не внедрял такое решение, но отчётливо помню что
>ещё в Windows NT 3.51 одно из первых виндовых
>кластерных решений базировалось именно на жестком диске, физически подключенном одновременно к
>всем узлам кластера. Он так же именовался ресурсом кворума.
>
>
>Насчёт семафоров - у вас просто не хватает фантазии)))) Вон
>езернет работает ведь без всяких семафоров))) ( классический, с коллизиями :-)
скорее у вас не хватает понимания. езернет может "слушать" физическую среду и "воздействовать" на нее _одновременно_! одновременно это ключевое слово. "классический" спинлок на "lock xchg" в x86 - это тоже "система с коллизиями" (инкрементим, если мы не единственные, то декрементим, ждем, инкрементим снова). только атомарность операции есть _необходимость_ для синхронизации.касаемо кластерных решений - а вы не путаете обычный диск и SAN (Storage-Area Network) ноду? если диск вставлен в некоторую "коробку", подключенную к нескольким серверам SCSI-шлейфами, то эта "коробка" может нести в себе часть логики ФС (а в случае настоящего SAN - таки полноценную ФС) и драйвер ФС в операционке нужен "комплементарный" этой железке (или ОС может разметить свою ФС поверх "виртуального" диска, "экспортируемого" SAN'ом)
\^P^/
>касаемо кластерных решений - а вы не путаете обычный диск и SAN
>(Storage-Area Network) ноду? если диск вставлен в некоторую "коробку", подключенную к
>нескольким серверам SCSI-шлейфами, то эта "коробка" может нести в себе часть
>логики ФС (а в случае настоящего SAN - таки полноценную ФС)
>и драйвер ФС в операционке нужен "комплементарный" этой железке (или ОС
>может разметить свою ФС поверх "виртуального" диска, "экспортируемого" SAN'ом)
>
>\^P^/Не путаю. Если даже диск не вставлен ни в какую коробку, а просто подключен к двум хост-контроллерам сразу, мы уже имеем ситуацию когда жесткий диск подключен одновременно к двум компьютерам. Такой-же ситуации можно достигнуть по fireware интерфейсу.
Ситуация когда диск подключен и разделяется между узлами кластера - есть базовая.
И действительно для меня подходят и GFS и OCFS2 - сейчас изучаю что для меня будет лучше.....
Ваши аналогии с семафорами не уместны.... каждая пишущая нода имеет свой индивидуальный журнал транзацкий в отдельной области обшего раздела.... единовременно только одна машина рулит транзакции, размещенные другими машинами. она выборная и меняется по ситуации.
>>касаемо кластерных решений - а вы не путаете обычный диск и SAN
>>(Storage-Area Network) ноду? если диск вставлен в некоторую "коробку", подключенную к
>>нескольким серверам SCSI-шлейфами, то эта "коробка" может нести в себе часть
>>логики ФС (а в случае настоящего SAN - таки полноценную ФС)
>>и драйвер ФС в операционке нужен "комплементарный" этой железке (или ОС
>>может разметить свою ФС поверх "виртуального" диска, "экспортируемого" SAN'ом)
>>
>>\^P^/
>
>Не путаю. Если даже диск не вставлен ни в какую коробку,
>а просто подключен к двум хост-контроллерам сразу, мы уже имеем ситуацию
>когда жесткий диск подключен одновременно к двум компьютерам. Такой-же ситуации
>можно достигнуть по fireware интерфейсу.
>
>Ситуация когда диск подключен и разделяется между узлами кластера - есть базовая.
>
>
>И действительно для меня подходят и GFS и OCFS2 - сейчас
>изучаю что для меня будет лучше.....
>
>Ваши аналогии с семафорами не уместны.... каждая пишущая нода имеет свой индивидуальный
>журнал транзацкий в отдельной области обшего раздела.... единовременно только одна машина
>рулит транзакции, размещенные другими машинами. она выборная и меняется по
>ситуации.невнимательно читаете
>>>ноды могут как-то синхронизировать свою работу
>>>через сеть
>>эээ... если постановка задачи это допускает, то возможно. только я плохо себе >>представляю драйвер ФС, который дергал бы сеть...
как я уже говорил, если кроме этого диска есть еще сетевой линк, то вполне возможно синхронизировать такую работу с диском. ИМХО все кластерные решения (будь то Oracle или кластер серверов Windows NT) используют именно такую схему
>>>или области диска.
[...]
а вот с этим вариантом - только "стандартный" диск и никакой другой связи между хостами - и были связаны все аналогии, и они тут вполне уместны.\^P^/
>а вот с этим вариантом - только "стандартный" диск и никакой другой
>связи между хостами - и были связаны все аналогии, и они
>тут вполне уместны.Если вы утверждаете, что два компьютера, имея для связи только жесткий диск, подключенный сразу к двум контроллерам, не способны в принципе организовать на нем вменяемую файловую систему, доступную обоим на RW, то вы меня так и не убедили но предлагаю больше не спорить, так как вероятно действительно FS сделанная так будет или иметь проблемы с блокировками,или весьма медленно работать и по сути такая реализация не нашла практического приложения)
>mount /dev/sdb1 /mnt/shared-hard-disk -o rw -t some_fsПосле команды mount начинается работа с ФС ;)
Работа с блочными девайсами - работа с /dev/sdX напрямую, так это проиходит, например, в базах данных которые могут работать с raw devices, без прослойки ФС. Далее кластера, к примеру Oracle RAC, могут работать с набором raw devices с разных машин, используя свой протокол синхронизации, etc..., но без фаиловой системы.
расшарить через NFS ?