LINUX.ORG.RU

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


0

0

На http://rhd.ru/ появился перевод статьи "Организация доступа к данным с помощью GFS". Оригинал был опубликован в Red Hat Magazine 2005 год 6 выпуск.

>>> Читать статью

anonymous

Проверено: Shaman007 ()

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

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

anonymous ()

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

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

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

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

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

monk ★★★★★ ()

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

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

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

Banshee ()

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

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

massaraksh ()

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

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

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

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

anonymous ()

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

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

xocolate ()

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

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

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

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

xocolate ()

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

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

anonymous ()

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

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

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

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

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

massaraksh ()

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

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

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

massaraksh ()

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

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

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

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

anonymous ()

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

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

anonymous ()

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

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

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

ivlad ★★★★★ ()

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

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

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

cvv ★★★★★ ()

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

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

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

Vond ★★ ()

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

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

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

Vond ★★ ()

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

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

massaraksh ()

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

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

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

cvv ★★★★★ ()

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

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

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.