Комментарии 30
было бы неплохо для совсем начинающих в этой теме немного упомянуть, что такое iSCSI, и для чего предназначен сервер iSCSI (тут смущенный смайлик)
я надеялся что народ хоть немного в курсе что это такое, да и проект в текущем виде больше предназначен для людей которых не пугает командная строка linux и т.п. вещи :)
> было бы неплохо для совсем начинающих в этой теме немного
> упомянуть, что такое iSCSI, и для чего предназначен сервер iSCSI
Позвольте, я вкратце объясню на пальцах.
Начну издалека.
Существуют две основные концепции сетевых хранилищ данных:
1) NAS (Network-attached storage)
en.wikipedia.org/wiki/Network-attached_storage
2) SAN (Storage area network), оно же Сеть хранения данных (СХД)
en.wikipedia.org/wiki/Storage_area_network
В случае NAS данные хранятся на неком сервере (часто с локально подключённым большим массивом дисков) и в сеть другим компьютерам они предоставляются в виде файлов по прикладным протоколам (SMB/CIFS, NFS, FTP, SFTP, HTTP, WebDAV, Direct Connect, BitTorrent и др.)
В случае SAN есть некий компьютер с большим дисковым массивом, но чаще даже не компьютер, а отдельная дисковая полка или целая дисковая стойка (сторадж). Дисковый объём этого хранилища нарезается на логические единицы LUN (Logical Unit Number) и в сеть хранения данных клиентам предоставляется (презентуется) именно LUN'ы (т.е. куски дискового пространства).
Создание в этом дисковом пространстве, предоставленном хранилищем, дисковых разделов, форматированием их в некую ФС и размещением там файлов занимается уже тот сервер, которому был презентован этот LUN. Само хранилище знает только о LUN'ах, и не знает ничего о более высокоуровневых логических структурах на этом диске (типа файловых систем и файлов).
Т.е. в NAS в сеть предоставляются файлы по высокоуровневым прикладным протоколам, а в SAN в сеть предоставляются диски (блочные устройства) в виде логических дисковых единиц LUN по более низкоуровневому протоколу дискового обмена (SCSI).
Так вот в случае SAN получается, что дисковое хранилище презентует куски своего дискового пространства множеству серверов. А каждый такой сервер по сети хранения данных «общается» с презентованным ему диском по протоколу SCSI.
И есть несколько вариантов среды для связи сервера, используещего диск, с дисковым хранилищем, презентующим диск.
Первый вариант:
1) Fibre Channel (FC)
en.wikipedia.org/wiki/Fibre_Channel
Это оптический канал. Если серверы и дисковое хранилище расположены в соседних стойках, то вся Fibre Channel инфраструктура может ограничиваться оптическими патчкордами, соединяющими FC-адаптеры сервера и дискового хранилища (впрочем, в этом случае хватило бы даже SCSI-кабеля).
В действительности же в организациях с большой IT-инфраструкутрой в SAN обычно входят множество дисковых стоек, множество оптических патч-кордов, множество FC-свитчей и FC-коммутаторов, множество магистральных оптических каналов. Как правило, все звенья FC-маршрута от сервера до хранилища ещё и дублируются (два FC-адаптера, два оптических патч-корда, два FC-коммутатора и т.д.), чтобы сервер имел доступ к диску по нескольким независимым путям (multipathing), чтобы обеспечивать резервирование в случае обрыва одного из маршрутов.
И второй вариант:
2) iSCSI
en.wikipedia.org/wiki/ISCSI
В этом случае команды протокола SCSI между сервером и дисковым хранилищем передаются в среде обычной Ethernet-сети, т.е. через обычный сетевой Ethernet-адаптер и обычную витую пару. Т.е. можно сказать, что iSCSI — это SCSI over Ethernet (а точнее даже SCSI over TCP/IP).
Для подключения дисков через iSCSI можно, конечно, использовать тот же сетевой интерфейс, который сервер использует для обычного сетевого обмена, но корпоративная сеть обычно и так заметно утилизирована различным обменом данными между серверами и клиентами, и это будет замедлять работу с диском по сети. Поэтому для организации инфраструктуры iSCSI обычно разворачивают отдельную гигабитную сеть, немаршрутизируемую с корпоративной Ethernet-сетью. Т.е. в серверах для доступа к дискам по iSCSI используется отдельный сетевой интерфейс, отдельные сетевые кабели, отдельные свитчи и маршрутизаторы, т.е. это физически отдельная сеть.
Но даже с учётом построения отдельной Ethernet-сети решение построения SAN на iSCSI гораздо дешевле, чем на оптике (можете посмотреть в прайсах стоимость FC-адаптеров/кабелей/свитчей/маршрутизаторов). iSCSI — это, что назвается, вариант реализации SAN для бедных. По скоростям дискового обмена он проигрывает оптике, но для относительно небольших компаний это вполне приемлемый вариант организации дискового хранилища и удалённого подключения с него дисков к множеству серверов.
Кроме оптики и витой пары раньше ещё можно было встретить реализацию SAN на медных кабелях, но такого вроде уже не встретить, поэтому другие варианты среды передачи в SAN рассматривать не буду.
Для презентования внутри SAN определённого диска (LUN'а) с дискового хранилища не всем подряд, а только определённому серверу, обычно используют некую привязку. При использовании Fibre Channel это может быть привязка к WWN (World Wide Name) — восьмибайтовый уникальный 16-ричный аппаратный номер FC-интерфейса (аналог MAC-адреса у Ethernet-интерфейсов). В случае использования iSCSI это может быть MAC-адрес или IP-адрес. Также дополнительно может быть парольная защита, чтобы кто угодно внутри этой сети не смог подключить определённый диск.
Так вот, возвращаясь к iSCSI… В клиент-серверной терминологии протокола iSCSI (впрочем, как и самого SCSI) есть такие понятия, как iSCSI Initiator и iSCSI Target.
iSCSI Initiator — это тот сервер, который подключает к себе по сети диск, презентованный ему с дискового хранилища.
А iSCSI Target — это соответственно сторона, предоставляющая диск (обычно это тот сервер, к которому этот диск/массив подключён фисически, например, через SATA/SCSI-контроллер). Любой сервер по отношению к какому-то таргету может выступать iSCSI Initiator'ом, и одновременно для других он сам может выступать в роли iSCSI Target, предоставляя в сеть свои дисковые ресурсы по iSCSI.
Собственно, в данном топике и представлен вариант Linux-дистрибутива (iSCSI Target Box), который можно установить на компьютер с кучей вместительных локальных жёстких дисков, чтобы с него презентовать эти диски другим компьютерам в сети по протоколу iSCSI (т.е. организовать там iSCSI Target).
> упомянуть, что такое iSCSI, и для чего предназначен сервер iSCSI
Позвольте, я вкратце объясню на пальцах.
Начну издалека.
Существуют две основные концепции сетевых хранилищ данных:
1) NAS (Network-attached storage)
en.wikipedia.org/wiki/Network-attached_storage
2) SAN (Storage area network), оно же Сеть хранения данных (СХД)
en.wikipedia.org/wiki/Storage_area_network
В случае NAS данные хранятся на неком сервере (часто с локально подключённым большим массивом дисков) и в сеть другим компьютерам они предоставляются в виде файлов по прикладным протоколам (SMB/CIFS, NFS, FTP, SFTP, HTTP, WebDAV, Direct Connect, BitTorrent и др.)
В случае SAN есть некий компьютер с большим дисковым массивом, но чаще даже не компьютер, а отдельная дисковая полка или целая дисковая стойка (сторадж). Дисковый объём этого хранилища нарезается на логические единицы LUN (Logical Unit Number) и в сеть хранения данных клиентам предоставляется (презентуется) именно LUN'ы (т.е. куски дискового пространства).
Создание в этом дисковом пространстве, предоставленном хранилищем, дисковых разделов, форматированием их в некую ФС и размещением там файлов занимается уже тот сервер, которому был презентован этот LUN. Само хранилище знает только о LUN'ах, и не знает ничего о более высокоуровневых логических структурах на этом диске (типа файловых систем и файлов).
Т.е. в NAS в сеть предоставляются файлы по высокоуровневым прикладным протоколам, а в SAN в сеть предоставляются диски (блочные устройства) в виде логических дисковых единиц LUN по более низкоуровневому протоколу дискового обмена (SCSI).
Так вот в случае SAN получается, что дисковое хранилище презентует куски своего дискового пространства множеству серверов. А каждый такой сервер по сети хранения данных «общается» с презентованным ему диском по протоколу SCSI.
И есть несколько вариантов среды для связи сервера, используещего диск, с дисковым хранилищем, презентующим диск.
Первый вариант:
1) Fibre Channel (FC)
en.wikipedia.org/wiki/Fibre_Channel
Это оптический канал. Если серверы и дисковое хранилище расположены в соседних стойках, то вся Fibre Channel инфраструктура может ограничиваться оптическими патчкордами, соединяющими FC-адаптеры сервера и дискового хранилища (впрочем, в этом случае хватило бы даже SCSI-кабеля).
В действительности же в организациях с большой IT-инфраструкутрой в SAN обычно входят множество дисковых стоек, множество оптических патч-кордов, множество FC-свитчей и FC-коммутаторов, множество магистральных оптических каналов. Как правило, все звенья FC-маршрута от сервера до хранилища ещё и дублируются (два FC-адаптера, два оптических патч-корда, два FC-коммутатора и т.д.), чтобы сервер имел доступ к диску по нескольким независимым путям (multipathing), чтобы обеспечивать резервирование в случае обрыва одного из маршрутов.
И второй вариант:
2) iSCSI
en.wikipedia.org/wiki/ISCSI
В этом случае команды протокола SCSI между сервером и дисковым хранилищем передаются в среде обычной Ethernet-сети, т.е. через обычный сетевой Ethernet-адаптер и обычную витую пару. Т.е. можно сказать, что iSCSI — это SCSI over Ethernet (а точнее даже SCSI over TCP/IP).
Для подключения дисков через iSCSI можно, конечно, использовать тот же сетевой интерфейс, который сервер использует для обычного сетевого обмена, но корпоративная сеть обычно и так заметно утилизирована различным обменом данными между серверами и клиентами, и это будет замедлять работу с диском по сети. Поэтому для организации инфраструктуры iSCSI обычно разворачивают отдельную гигабитную сеть, немаршрутизируемую с корпоративной Ethernet-сетью. Т.е. в серверах для доступа к дискам по iSCSI используется отдельный сетевой интерфейс, отдельные сетевые кабели, отдельные свитчи и маршрутизаторы, т.е. это физически отдельная сеть.
Но даже с учётом построения отдельной Ethernet-сети решение построения SAN на iSCSI гораздо дешевле, чем на оптике (можете посмотреть в прайсах стоимость FC-адаптеров/кабелей/свитчей/маршрутизаторов). iSCSI — это, что назвается, вариант реализации SAN для бедных. По скоростям дискового обмена он проигрывает оптике, но для относительно небольших компаний это вполне приемлемый вариант организации дискового хранилища и удалённого подключения с него дисков к множеству серверов.
Кроме оптики и витой пары раньше ещё можно было встретить реализацию SAN на медных кабелях, но такого вроде уже не встретить, поэтому другие варианты среды передачи в SAN рассматривать не буду.
Для презентования внутри SAN определённого диска (LUN'а) с дискового хранилища не всем подряд, а только определённому серверу, обычно используют некую привязку. При использовании Fibre Channel это может быть привязка к WWN (World Wide Name) — восьмибайтовый уникальный 16-ричный аппаратный номер FC-интерфейса (аналог MAC-адреса у Ethernet-интерфейсов). В случае использования iSCSI это может быть MAC-адрес или IP-адрес. Также дополнительно может быть парольная защита, чтобы кто угодно внутри этой сети не смог подключить определённый диск.
Так вот, возвращаясь к iSCSI… В клиент-серверной терминологии протокола iSCSI (впрочем, как и самого SCSI) есть такие понятия, как iSCSI Initiator и iSCSI Target.
iSCSI Initiator — это тот сервер, который подключает к себе по сети диск, презентованный ему с дискового хранилища.
А iSCSI Target — это соответственно сторона, предоставляющая диск (обычно это тот сервер, к которому этот диск/массив подключён фисически, например, через SATA/SCSI-контроллер). Любой сервер по отношению к какому-то таргету может выступать iSCSI Initiator'ом, и одновременно для других он сам может выступать в роли iSCSI Target, предоставляя в сеть свои дисковые ресурсы по iSCSI.
Собственно, в данном топике и представлен вариант Linux-дистрибутива (iSCSI Target Box), который можно установить на компьютер с кучей вместительных локальных жёстких дисков, чтобы с него презентовать эти диски другим компьютерам в сети по протоколу iSCSI (т.е. организовать там iSCSI Target).
На самом деле развернуть iSCSI Target легко в любом дистрибутиве. На ubuntu server и SLES это делается оооооооочень просто.
Было бы значительно интереснее добавить сюда отказоустойчивость. IETD-то на любой linux поставить несколько минут.
Что Вы имеете ввиду под отказоустойчивостью target??
Два хоста с непрерывным зеркалированием данных. С точки зрения потребителя это выглядит как multi-path
Тогда два хоста должны иметь общее хранилище, к которому тоже надо както обеспечить доступ (по томуже iSCSI) и оно тоже должно быть мегаустойчивое…
IMHO всетаки эта задача не должна решатся на уровне iSCSI который по сути является SCSI-контроллером с удлиненными по IP соединительными «проводами»…
IMHO всетаки эта задача не должна решатся на уровне iSCSI который по сути является SCSI-контроллером с удлиненными по IP соединительными «проводами»…
Если же тупо зеркалировать данные, то поднимаем кластерную файловую систему на drbd на этом же Box'е добавив пару компонент в сборку
Может быть опишете подробно как это делается с примером конфигурации?
Вот хорошее описание DRBD — www.xgu.ru/wiki/Drbd
В самом iSCSI Target Box исправить в mkinitcpio.conf строки
MODULES=«crc32c iscsi_trgt drbd»
BINARIES=«agetty /lib/libnss_dns.so.2 drbdadm drbdsetup»
Да подсунуть drbd.conf в /iscsi-target-etc
В самом iSCSI Target Box исправить в mkinitcpio.conf строки
MODULES=«crc32c iscsi_trgt drbd»
BINARIES=«agetty /lib/libnss_dns.so.2 drbdadm drbdsetup»
Да подсунуть drbd.conf в /iscsi-target-etc
Есть еще неплохое решение, особенно когда надо быстро машинку с iSCSI поднять. Openfiler. Имеет удобный веб-интерфейс. У меня на работе с такой штукой отлично бегает Citrix XenServer халявный. Развернул за час iSCSI плюс chanel-bonding. Все завелось с пол-пинка. Понимаю, что все гуевины и веб-интерфейсы это от лукавого, но иногда время дороже.
Кроме этого дистрибутива предлагаю посмотреть ещё несколько вариантов маленьких nix-дистрибутивов, заточенных на создание NAS-сервера или SAN (а именно iSCSI Initiator/Target).
Как правило, такие дистрибутивы делаются с простой установкой (или даже liveCD) и удобным управлением через web-консоль. Т.е. проинсталлировал, в пару кликов настроил, и оно уже работает, как удобный файловый сервер и дисковое хранилище.
1) FreeNAS — freenas.org/
Дистрибутив на базе FreeBSD.
2) Openfiler — www.openfiler.com/
Дистрибутив на базе Linux.
Кстати, автор FreeNAS решил не продолжать дальнейшее развитие этого проекта (как я понял, там никакие новые фичи уже не внедряются, только исправление ошибок).
Вместо этого он решил полностью переписать FreeNAS, чтобы перевести его с FreeBSD на базу Debian Linux.
Сам этот проект по переписыванию FreeNAS под Debian изначально получил промежуточное имя СoreNAS, а в дальнейшем сам дистрибутив на базе Linux будет называться OpenMediaVault
openmediavault.org/
Как правило, такие дистрибутивы делаются с простой установкой (или даже liveCD) и удобным управлением через web-консоль. Т.е. проинсталлировал, в пару кликов настроил, и оно уже работает, как удобный файловый сервер и дисковое хранилище.
1) FreeNAS — freenas.org/
Дистрибутив на базе FreeBSD.
2) Openfiler — www.openfiler.com/
Дистрибутив на базе Linux.
Кстати, автор FreeNAS решил не продолжать дальнейшее развитие этого проекта (как я понял, там никакие новые фичи уже не внедряются, только исправление ошибок).
Вместо этого он решил полностью переписать FreeNAS, чтобы перевести его с FreeBSD на базу Debian Linux.
Сам этот проект по переписыванию FreeNAS под Debian изначально получил промежуточное имя СoreNAS, а в дальнейшем сам дистрибутив на базе Linux будет называться OpenMediaVault
openmediavault.org/
НЛО прилетело и опубликовало эту надпись здесь
Думаю не проблема т.к. поддержка NFS находится в ядре и все что надо так это добавить в init-скрипт несколько строчек.
Рекомендую написать об этом на багтрекере проекта.
Рекомендую написать об этом на багтрекере проекта.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В общем то почти все есть в стандартном mkinitcpio скрипте Arch'а.
На вики есть подробная статья о загрузке с NFS.
Надо добавить в mkinitcpio.conf в секцию MODULES=«nfs» и прописать в строке инициализации ядра что то типа:
На вики есть подробная статья о загрузке с NFS.
Надо добавить в mkinitcpio.conf в секцию MODULES=«nfs» и прописать в строке инициализации ядра что то типа:
root=/dev/nfs nfsroot=10.0.0.1:/disklessroot,v3,rsize=16384,wsize=16384 ip=::::::dhcpНЛО прилетело и опубликовало эту надпись здесь
Если честно, то уже нет необходимости в внешнем iscsi хранилище, потому к проекту пока чисто спортивный интерес.
Т.к. здесь используются только стандартные компоненты типа ядра, таржета и базибокса, а кастомизированы только скрипты инициализации то думаю использовать в продакшине сборку на стабильных компонентах не менее надежно чем в обычном дистрибутиве.
Т.к. здесь используются только стандартные компоненты типа ядра, таржета и базибокса, а кастомизированы только скрипты инициализации то думаю использовать в продакшине сборку на стабильных компонентах не менее надежно чем в обычном дистрибутиве.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
iSCSI Target Box