В производстве возникла задача построить единое хранилище данных на небольшую сеть (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.
Будут вопросы: с удовольствием отвечу.