Перевод статьи «Организация доступа к данным с помощью GFS»

А ошибочки то придется поправить -)

> Построение бездисковых кластеров с разделяемым корневым разделом с ? использованием GFS является специфической задачей и зависит от оборудования и версии ядра, и эту возможность можно реализовать только с помощью специалистов компании Red Hat или партнеров Red Hat, таких как ATIX GmbH.

Так технология закрытая, что ли?

> Два года назад IP Tech перешла на Red Hat GFS и, в противоположность их инфраструктуре с хранилищем, построенным на NFS, кластер работающий на Red Hat GFS "работал сам сбой"

Хорошая опечатка в последнем слове...

У этой вещи куча недостаткой, самым ярким из которых является отсутствие рековери...

Кроме того вызывает большие сомнения целесообразность постоения кластерной файловой системы по принципу расшареного в сети стораджа.

уже несколько раз пытался посмотреть на gfs, но че-то никак не пойму.
может эта штука синхронизировать локальные дисковые массивы наподобие drbd, но в multi-active режиме или она только разруливает доступ к некоему shared storage?
т.е. что бы мне хотелось иметь - это подобие nfs, но high-available и c load-balancing. т.е. некое множество файл-серверов с локальными дисками, данные на которых всегда синхронизированы а сервер, обслуживающий соединение выбирается по принципам lvs.

Угу. При некотором кол-ве серверов они будут заниматься тем, что будут синхронизировать данные друг с другом, а не обслуживать клиентов. Или вы наивно полагаете, что данные синхронизируются мнгновенно?

drbd не масштабируется. Попробуйте включить в кластер более 3-х серверов используя drbd.

LVS хорош для распределения запросов на обслуживание. Однако я не представляю алгоритма учитывающего "правильность" данных на каждом сервере. Ведь именно на правильные и актуальные данные нужно отправлять клиентов, не так ли? Проблема...

Да никто ничего не синхронизирует ... просто ОДИН диск подцеплен к n-линухам .. и они доступаются к одной файловой системе прозрачно - как до своего локального диска.

поправка к посту выше - как минимум один диск ..

если скажем подцепить такой диск с ext2/3 файловой системой то при конкурентных запросах фс превратится в полный хаус, в этой вроде как борются с этим ..

это удобно как раз отсутствием синхронизации ... например оракл цепляют в кластер и несколько инстансов на разных машиных доступаются до одной и той же базы ... без всяких реплик ( утрированно )

а где почитать, как сделать RAC на GFS?

Я думал это GPS приспособили так хитро, а это...тьфу GFS какое-то.

>Угу. При некотором кол-ве серверов они будут заниматься тем, что будут синхронизировать данные друг с другом, а не обслуживать клиентов. Или вы наивно полагаете, что данные синхронизируются мнгновенно?

> drbd не масштабируется. Попробуйте включить в кластер более 3-х серверов используя drbd.

> LVS хорош для распределения запросов на обслуживание. Однако я не представляю алгоритма учитывающего "правильность" данных на каждом сервере. Ведь именно на правильные и актуальные данные нужно отправлять клиентов, не так ли? Проблема...

нет, не мгновенно конечно, но при относительно небольшом кол-ве серверов, скажем до 10 и на задачах где чтение происходит на несколько порядков чаще чем запись, для каковых я и приглядываюсь к gfs/drbd/whatever - я думаю производительность будет приемлемая даже с синхронной записью, что заодно и решает проблему с lvs. я не прав?

> Да никто ничего не синхронизирует ... просто ОДИН диск подцеплен к n-линухам .. и они доступаются к одной файловой системе прозрачно - как до своего локального диска.

так я и думал. а за счет чего достигается redundancy? за счет raidов на storage?

Позор, а не перевод!

Там жирным шрифтом написано "Мастабируемость"

Но я сделал доброе дело - отправил переводчику ссылку на www.gramota.ru

а я думал неужели google file system

> Я думал это GPS приспособили так хитро, а это...тьфу GFS какое-то.

главное - что не GPF, правда? ;)

>т.е. что бы мне хотелось иметь - это подобие nfs, но high-available и c load-balancing. т.е. некое множество файл-серверов с локальными дисками, данные на которых всегда синхронизированы а сервер, обслуживающий соединение выбирается по принципам lvs.

тебе нужен AFS или DFS. GFS ето *совсем* другая песня

"Мастурбироемость"?

Вам нужен не GFS а AFS. Посмотрите openafs.

> так я и думал. а за счет чего достигается redundancy? за счет raidов на storage?

Не только. Ещё, к примеру, за счёт дублирования FibreChannel контроллеров, FibreChannel свичей, дублированием контроллеров на каждом диске.

> дублированием контроллеров на каждом диске

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

На Lustre посмотри, да?

да

Главное, что не GTF ;-)

openafs я видел. пробежался, правда признаюсь очень поверхностно по readme и у меня осталось впечатление, что для production оно еще довольно сырое. за lustre - спасибо. посмотрю.
у кого-нить есть реальный опыт использования этих проектов? очень интересуют впечатления, плюсы/минусы и т.д.

>openafs я видел. пробежался, правда признаюсь очень поверхностно по readme и у меня осталось впечатление, что для production оно еще довольно сырое.

версии 1.2.11/1.2.13 для production самый раз.

Дуралей, прям...

Отказоустойчивость достигается тем, что в коробке с дисками стоит 2 контроллера и хитрая платочка, которая следит за их здоровьем и отказавшее отключает. Сами диски естественно в RAID нужный собираются. К ящику с дисками существует по крайней мере 2 линка (по Fibre Chanell или Ethernet - не очень важно). Соответственно если нужно и сервакам обеспечить надежный коннект к дискам - то и в них 2 линка. Линки сводятся на свичи, которые вяжутся 2-мя или более линками.

В итоге имеем надежное и шустрое хранилище. Подключай серваки по мере надобности и радуйся.