LINUX.ORG.RU

Настройка iSCSI target и initiator в RHEL/Fedora

 


0

0

Как известно, при использовании существующей сетевой инфраструктуры iSCSI представляет собой недорогую альтернативу FC, а для целей обучения и тестирования вообще не заменим, поскольку, в ряде случаев, можно обойтись без дорогостоящего оборудования. Безусловно, существует и множество "боевых" конфигураций, когда по тем или иным причинам стоит отдать предпочтение iSCSI. Для демонстрации используем две машины: vm01, которая будет экспортировать заданный раздел, и vm02, на которой настроим инициатор.

>>> Подробности

★★

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

А как множетсво компьютеров работающих с хранилищем через iSCSI синхронизуется? Или используется специальная файловая система поверх этого всего?

OxiD ★★★★
()
Ответ на: комментарий от OxiD

С iscsi работает либо только один сервер, либо используется распределенная файловая система.

iscsi - это сетевое блочное устройство как nbd, aoe, dst, drbd. У каждого свои достоинства и недостатки, единственным достоинством iscsi являетс я возможность легкого подключения хранилищ к/вместо существующих scsi хранилищ (по сути просто scsi команды и данные бегают по сети, а не сказёвому шлейфу).

rtc ★★
()
Ответ на: комментарий от anonymous

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

Серверы Sun на вторых ультраспарках (U3000 итп.) появились как раз лет 10 назад. И работают до сих пор. Недавно наблюдал экземпляр с аптаймом в 4 года. Крутит SAP. Обслуживает несколько сотен пользователей. В гроб не собираются.

serg_junior
()
Ответ на: комментарий от anonymous

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

зря вы так про хлам, например VAX'ы до сих пор кое-где используются, у нас на ВЦ не так давно выкинули и представьте себе, он делал полезную работу. иногда нужно, чтобы было поставлено, включено и пахало условно скажем полвека, прогресс нужен не везде, надёжность иногда намного важнее производительности, если решённая задача не меняется полвека, то зачем ей прогресс? (и конечно же потребление электричества и занимаемое место тоже не всегда важнее надёжности).

filin ★★
()
Ответ на: комментарий от rtc

> iscsi - это сетевое блочное устройство как nbd, aoe, dst, drbd. У каждого свои достоинства и недостатки, единственным достоинством iscsi являетс я возможность легкого подключения хранилищ к/вместо существующих scsi хранилищ (по сути просто scsi команды и данные бегают по сети, а не сказёвому шлейфу).

ээээ... не совсем понял ремарку по поводу "единственного" а так же "простоту подключения вместо существующих SCSI".

вот есть у меня, скажем, большой толстый сторадж, из него тянется большой широкий шлейф и втыкается в SCSI порт на контроллере на матери. и надоел мне этот сторадж и захотел я его поменять. и выбираю, что взять: на FC или на iSCSI.

внимание, вопрос: чем принципиально вариант с iSCSI будет проще по сравнению с FC?

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> ну или такой сценарий: назрела необходимость наращивать ресурсы системы. вам уже не хватает пары локальных дисков в сервере в стрипе а таки понадобилось несколько терабайт причём в RAID5/6. причём это - не последний апгрейд и через год вполне возможно вам понадобится ещё N терабайт.

> или вы апгрейдите свою существующую инфраструктуру, выбирая/покупая/ожидая/заменяя/переставляя/перетестируя и тд и тп свои боевые сервера, или же вы берёте ещё одну коробочку в пару U в стойку ну и, если ещё нет, гигабитный свич. последнее интегрируется в систему и вводится в рабочее состояние в течении одного рабочего дня практически без down time.

красиво написано, а на деле? насколько легко и быстро добавить ещё места например в редхетовской GFS?

в GlusterFS при включённой избыточности это делается без "down time", просто некоторое время нужный storage node на обслуживании, а его данные зарезервированные на других нодах раздаются клиентам с них (я пробовал, работает)

filin ★★
()
Ответ на: комментарий от filin

> красиво написано, а на деле?

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

> насколько легко и быстро добавить ещё места например в редхетовской GFS?

почему именно GFS? с точки зрения системы появляется обычное блочное устройство[а], на которых вы можете разместить ту файловую систему, которая вам больше нравится. если вам нужен именно шустрый толстый "винт" в пределах сервера а не в кластере, зачем вам там GFS? use ext3, reiser или кому что по душе.

> в GlusterFS при включённой избыточности это делается без "down time", просто некоторое время нужный storage node на обслуживании, а его данные зарезервированные на других нодах раздаются клиентам с них (я пробовал, работает)

ничего не скажу про GFS, не пробовал. с хранилищами FC/iSCSI общаться приходилось, в принципе общая идея вынесения дисковой подсистемы за пределы сервера и её виртуализация вполне понравилась. к примеру, сидя дома я могу через WEB полностью перестроить инфраструктуру небольшого датацентра за минимальное время не прикасаясь при этом к железу да и вообще никогда его не видя в глаза [оно там, на Луне]. удобно. естественно в случае, если требуемые хранилища уже подключены физически к серверам и пр.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> к примеру, сидя дома я могу через WEB полностью перестроить инфраструктуру небольшого датацентра за минимальное время не прикасаясь при этом к железу да и вообще никогда его не видя в глаза [оно там, на Луне]. удобно. естественно в случае, если требуемые хранилища уже подключены физически к серверам и пр.

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>внимание, вопрос: чем принципиально вариант с iSCSI будет проще по сравнению с FC?

Все, что угодно, будет лучше, чем FC :)

Потому что FC очень дорого, ОЧЕНЬ дорого. Сейчас всё постепенно движется в сторону сетевых хранилищ и доступа с использованием существующей сетевой инфраструктуры. Поэтому рассматривать можно iscsi по сравнению с fcoe. Первый быстрее, надежнее, работает для разных сегментов цепи, и, главное, ну убивает нах весь сегмент сети, подключенный к данному свичу, когда начинает броадкастить свои запросы в несчастную железку (есть у fcoe такая беда). Специальные fcoe-avare свичи стоят таких нереальных денег, что об этом лучше даже не заикаться.

Поэтому fcoe может работать только в одном сегменте сети, но даже там технология не очень отточена и есть масса неприятных железных (драйверных) глюков. Плюс, intel строит fcoe чипы на базе своего кривого e1000, у которого проблемы с jumbo фреймами: из-за того, что кто-то сэкономил пару центов на дополнительных адресных линиях, в старых и "средних" моделях нельзя делать DMA в несколько блоков, только в один непрерывный, поэтому очень неприятно работает это дело в ядре...

rtc ★★
()
Ответ на: комментарий от filin

>в GlusterFS при включённой избыточности это делается без "down time", просто некоторое время нужный storage node на обслуживании, а его данные зарезервированные на других нодах раздаются клиентам с них (я пробовал, работает)

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

rtc ★★
()
Ответ на: комментарий от klalafuda

>почему именно GFS? с точки зрения системы появляется обычное блочное устройство[а], на которых вы можете разместить ту файловую систему, которая вам больше нравится. если вам нужен именно шустрый толстый "винт" в пределах сервера а не в кластере, зачем вам там GFS? use ext3, reiser или кому что по душе.

В GFS несложно, но она нужна только тогда, когда нужна кластерная ФС и _только_ тогда, когда вам запрещено использовать что-то еще.

GFS очень медленная и слабо масштабируется. Даже gfs2.

rtc ★★
()
Ответ на: комментарий от tailgunner

> А какие грабли с bonding?

Да огромные. На гигабите возможен только failsafe bonding. Ни один из видов бондинга, позволяющий поднять скорость на практике не работает. Ok, уточняю - есть две железки, у каждой две гигабитных сетевухи. Задача получения двухгигабитного канала не решается.

Просто сделать, чтобы из сервера уходило несколько гигабит разным клиентам можно - но смысла особого нет, проще каждой сетевухе IP выставить и прописать каждому клиенту свой, или в DNS раскидывать между ними.

А эти замечательные "шесть методов" дают либо failsafe, либо не лучше метода с несколькими IP, либо дают замедление (если распределять одно соединение, то tcp/ip стеку становится плохо от извратной очередности пакетов, и скорость падает мегабит до 500). Методы распределения, ставящие одинаковые MAC'и вдобавок требуют соединения без свитча, либо раздельных групп свитчей, либо хитрой настройки vlan'ов - потому что любой свитч кэширует, что устройство с таким-то MAC на таком-то порту, и в упор отказывается посылать пакеты на другой, даже если там такой же MAC.

Ах ну да, еще удачи в стыковки линуксового bonding'а с солярисовской агрегацией.

В общем, по результатам многочисленных экспериментах на разных системах я пришел к тому, что никакие решения, кроме 10GigE в реальных задачах, где нужно между двумя хостами по nfs получить больше гигабита невозможны. Теоретически вариантов масса, практически - жопа.

anonymous
()
Ответ на: комментарий от anonymous

> В общем, по результатам многочисленных экспериментах на разных системах я пришел к тому, что никакие решения, кроме 10GigE в реальных задачах, где нужно между двумя хостами по nfs получить больше гигабита невозможны. Теоретически вариантов масса, практически - жопа.

встраивайте сборку потока данных с NxGb в application layer, если вам ОЧЕНЬ это нужно, оформите в виде библиотеки, с подменой сокетных сисколов на этапе загрузки вашей библиотеки (и на клиенте и на сервере), добавите путь к ней в LD_PRELOAD и тогда даже бинарники приложения перекомпилячивать не нужно (да это хак, но работающий, часто используемый при reverse engineering). Если выложите в сорсах, я думаю найдутся желающие попользовать и развивать дальше. Это ПРАКТИЧЕСКИЙ вариант хоть и не на все случаи жизни и совсем не требующий суперразработчика.

filin ★★
()
Ответ на: комментарий от rtc

> Когда glusterfs перестанет падать от малейшего нестандартного чиха, ее можно будет использовать... Кстати, они уже зеркалирование перетащили из альфа-ветки?

да, проблемы у glusterfs есть, но у меня на тестах она не падает, баги разработчики фиксят быстро. glusterfs НЕ ПОЗИЦИОНИРУЕТСЯ как общецелевая кластерная фс с полной поддержкой позикс, по крайней мере пока, если нужна такая пользуйте редхатовскую gfs

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

вы неправы, afr транслятор одна из важных фич glusterfs, скорее всего вы неправильно вспомнили stripe транслятор, его действительно добавили по многочисленным запросам пользователей.

http://www.gluster.org/docs/index.php/GlusterFS_FAQ#You_say_striping_is_bad.2...

filin ★★
()
Ответ на: комментарий от filin

>вы неправы, afr транслятор одна из важных фич glusterfs, скорее всего вы неправильно вспомнили stripe транслятор, его действительно добавили по многочисленным запросам пользователей.

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

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