В производстве возникла задача построить единое хранилище данных на небольшую сеть (20 рабочих станций).
Типовые и тривиальные варианты в виде сетевых шарингов или мапингов по NFS отпали, в виду того, что сети в 1Гбит весьма мало для наших задач, а решения в 10Гбит в России носят скорее теоретический характер, потому как: во-первых, дорого очень, во-вторых, недоступно. Купить, например, полноценный свитч на 16 портов по 10Гбит каждый — откровенно невозможно. Или за очень много денег опять же. Хотя что происходит сейчас на рынке железа, я скажу честно, уже не в курсе. Так как то что уже построили — не ломать же.
Перейдем в таком случае к варианту, который работает у нас. Сеть на основе Fibre Channel.
Итак, топология сети выглядит весьма тривиально:
три различных стораджа с dual контроллерами смотрят в два разных свитча Qlogic SANbox 5600.
В эти же свитчи раскиданы пользователи поровну + основной файл-сервер смотрит двумя контроллерами в оба свитча.
Примерно вот так это выглядит со стороны серверной:
сверху идут 5 полок Sanbloc на старых добрых SCSI общим объемом на полку 1Тб в 5-м рейде.
Далее идет файл-сервер, о котром упоминалось в конфигурации,
после сервера: 3 полки (Xyratex F5412E + slave и Xyratex F6412E) на SATA, но там бутерброды из Raid0 и Raid10.
И в самом низу, не влезло в кадр: ленточная библиотека ADIC Scalar 100 на 60 лент, старых по нынешним меркам LTO-2 драйвами, которая служит средством сброса данных для долгосрочного хранения (и бекапа как такового)и надеждой, что данные никогда не понадобятся.
Ну и пара кадров обратной стороны (не надейтесь, красоты не выйдет с красиво уложенными кабелями)
Теперь о том, как это работает.
Все нарезанные LUN-ы на стораджах, если они не размаплены, то видны всем пользователям сразу, в нашем случае все LUN смаплены на файлсервер, и только 1, нарезанный в общее пользование не размаплен и доступен всем. Он то нас и интересует. Для каждого пользователя такой LUN доступен как отдельный жесткий диск, при этом все видят хранящиеся на нем данные.
Но как известно, большинство файловых систем не поддерживает немонополизированного использования, за исключением кластерных, таких как микрософтовский cfs или zfs от IBM.
Классический ntfs при совместном использовании в конечном счете приведет к полному краху файловой структуры. Можно конечно применить примеры выше: cfs или zfs — но в первом варианте прийдется всем ставить windows server, во-втором случае покупать лицензию, с весьма не гуманным ценником. Врать не буду, но последний раз цена была озвучена около 5к уе за каждого клиента.
Есть также другой вариант — xSAN от яблочной компании, но привязываться к MAC OS X совсем не хочется, так как в работе используются в своем большинстве windows-приложения, поэтому вариант смены операционки также не рассматривали.
Есть полумера, к которой и прибегнули: надстройка над файловой системой, под названием MetaSAN. Кому интересно — могут почитать детально на tiger-technology.com.
Вкратце же, работает это так, клиент MetaSAN выступает драйвером между LUN и операционной системой, все операции чтения-записи данных ведутся напрямую по Fibre Channel, а изменения в файловую структуру передаются основному контроллеру MetaSAN по обычной сети, в таком случае мы имеем производительность дисков до 4Гбит по оптике, и совсем малый поток информации по езернету.
Слабым местом в данном случае, выступает контроллер данных, но он может назначаться автоматически любой машине, либо средствами приоритезации непосредственно недоступной обычным юзерам машине, в нашем случае файл-серверу, который, как правило, всегда доступен, к тому же имеет избыточное подключение к стораджам через multi-Path.
И в качестве ремарки:
любые варианты использования обычного ethernet (nfs, smb, iscsi) в классических пониманиях для передачи файлов не очень подходят, по банальной причине задержек в сети. Большинство пользователей работает с некомпрессированным FullHD контентом, и ethernet в силу своих особенностей, не способен выдавать данные с минимальными одинаково-постоянными задержками, что сильно осложняет playback FullHD video.
Будут вопросы: с удовольствием отвечу.
Типовые и тривиальные варианты в виде сетевых шарингов или мапингов по NFS отпали, в виду того, что сети в 1Гбит весьма мало для наших задач, а решения в 10Гбит в России носят скорее теоретический характер, потому как: во-первых, дорого очень, во-вторых, недоступно. Купить, например, полноценный свитч на 16 портов по 10Гбит каждый — откровенно невозможно. Или за очень много денег опять же. Хотя что происходит сейчас на рынке железа, я скажу честно, уже не в курсе. Так как то что уже построили — не ломать же.
Перейдем в таком случае к варианту, который работает у нас. Сеть на основе Fibre Channel.
Итак, топология сети выглядит весьма тривиально:
три различных стораджа с dual контроллерами смотрят в два разных свитча Qlogic SANbox 5600.
В эти же свитчи раскиданы пользователи поровну + основной файл-сервер смотрит двумя контроллерами в оба свитча.
Примерно вот так это выглядит со стороны серверной:
сверху идут 5 полок Sanbloc на старых добрых SCSI общим объемом на полку 1Тб в 5-м рейде.
Далее идет файл-сервер, о котром упоминалось в конфигурации,
после сервера: 3 полки (Xyratex F5412E + slave и Xyratex F6412E) на SATA, но там бутерброды из Raid0 и Raid10.
И в самом низу, не влезло в кадр: ленточная библиотека ADIC Scalar 100 на 60 лент, старых по нынешним меркам LTO-2 драйвами, которая служит средством сброса данных для долгосрочного хранения (и бекапа как такового)и надеждой, что данные никогда не понадобятся.
Ну и пара кадров обратной стороны (не надейтесь, красоты не выйдет с красиво уложенными кабелями)
Теперь о том, как это работает.
Все нарезанные LUN-ы на стораджах, если они не размаплены, то видны всем пользователям сразу, в нашем случае все LUN смаплены на файлсервер, и только 1, нарезанный в общее пользование не размаплен и доступен всем. Он то нас и интересует. Для каждого пользователя такой LUN доступен как отдельный жесткий диск, при этом все видят хранящиеся на нем данные.
Но как известно, большинство файловых систем не поддерживает немонополизированного использования, за исключением кластерных, таких как микрософтовский cfs или zfs от IBM.
Классический ntfs при совместном использовании в конечном счете приведет к полному краху файловой структуры. Можно конечно применить примеры выше: cfs или zfs — но в первом варианте прийдется всем ставить windows server, во-втором случае покупать лицензию, с весьма не гуманным ценником. Врать не буду, но последний раз цена была озвучена около 5к уе за каждого клиента.
Есть также другой вариант — xSAN от яблочной компании, но привязываться к MAC OS X совсем не хочется, так как в работе используются в своем большинстве windows-приложения, поэтому вариант смены операционки также не рассматривали.
Есть полумера, к которой и прибегнули: надстройка над файловой системой, под названием MetaSAN. Кому интересно — могут почитать детально на tiger-technology.com.
Вкратце же, работает это так, клиент MetaSAN выступает драйвером между LUN и операционной системой, все операции чтения-записи данных ведутся напрямую по Fibre Channel, а изменения в файловую структуру передаются основному контроллеру MetaSAN по обычной сети, в таком случае мы имеем производительность дисков до 4Гбит по оптике, и совсем малый поток информации по езернету.
Слабым местом в данном случае, выступает контроллер данных, но он может назначаться автоматически любой машине, либо средствами приоритезации непосредственно недоступной обычным юзерам машине, в нашем случае файл-серверу, который, как правило, всегда доступен, к тому же имеет избыточное подключение к стораджам через multi-Path.
И в качестве ремарки:
любые варианты использования обычного ethernet (nfs, smb, iscsi) в классических пониманиях для передачи файлов не очень подходят, по банальной причине задержек в сети. Большинство пользователей работает с некомпрессированным FullHD контентом, и ethernet в силу своих особенностей, не способен выдавать данные с минимальными одинаково-постоянными задержками, что сильно осложняет playback FullHD video.
Будут вопросы: с удовольствием отвечу.