Памятка начинающей студии

Когда то я работал в одной молодой, но очень бурно развивающейся компании. Пока проекты были скромные по размерам все шло вполне успешно. Но когда проекты начали разрастаться как по сложности, так и по объемам, так и по количеству рендер нод, так и по количеству сотрудников, то тут нас ожидал очень неприятный сюрприз – а как же обеспечить совместную быструю, простую и удобную работу для всей этой студии. И к сожалению ни ответственными специалистами, ни кем либо другим решение не было найдено, в итоге проект начал проседать под собственным весом. Я через некоторые время не выдержал этой агонии и уволился, а сам проект еще через год был закрыт.

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

Речь пойдет о следующих масштабах: более 100 сотрудников, более 200 рендер нод, более 100 ТБ единого файлового хранилища, более 30 Гб/с скорость файлового хранилища. Некоторые из приведенных здесь идей являются проверенными и являются реально действующими, некоторые приведены на уровне теории и эффект может оказаться непредсказуемым. Вся информация приведенная в статье приведена для размышления, и не имеет законченного логического решения. Все специализированные и сложные термины попытаюсь объяснить простым и доступным языком, пусть и не всегда технически точным, для детальных объяснений есть wiki.

 

Раздел 1. Сеть хранения данных

Первое что необходимо решить студии – это конечно где хранить рабочие файлы. Для этого специально покупается файловый сервер, допустим на 24 ТБ. Но со временем его начинает не хватать как по объемам так и по скорости работы. Тогда покупается второй сервер. И тут встает вопрос как раскидать файлы между двумя серверами. Кое как эта проблема решается. А тут и двух серверов начинает не хватать, купить еще сервер. Но как теперь файлы раскидывать? Понятно что так жить нельзя, образуется хаос и неразбериха. Кроме того если разом стартует 100 рендер нод, они разом грузят данные файлы сцен и текстур с сервера. Из за чего сервер надолго задумывается и недоступен для сотрудников.

Первым делом что необходимо решить это как и из чего будет устроено наше хранилище. А оно должно отвечать следующим требование:

  • хранилище должно быть единым, т.е. при добавлении нового сервера файловая структура оставалась та же, а его объемы и скорость увеличивались;
  • хранилище должно легко масштабироваться, т.е. чтобы мы в любой момент без остановки его работы можно было увеличить его объем или скорость;
  • хранилище должно быть высокодоступным, т.е. время его доступности для всех пользователей должно быть выше 99,9%;
  • хранилище должно быть отказоустойчивым, т.е. любой из элементов хранилища должен иметь возможность горячей замены без потери доступности для пользователей.

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

 

Часть 1. Программный SAN. Протокол iSCSI.

Для начала давайте разберемся в терминологии. Какие же типы хранилищ бывают:

  • NAS (Network Attached Storage) – сетевое хранилище, компьютер набитый винчестерами для общего доступа по сети.
  • SAN (Storage Area Network) – сеть хранения данных, несколько NAS в одной сети.

А теперь давайте разбираться как же нам несколько NAS объединить в SAN. Для этого есть множество разных протоколов.

  • SMB (Server Message Block) – это всем нам знакомый протокол для расшаривания файлов, принтеров и прочих ресурсов по сети;
  • SCSI (Small Computer System Interface) – иногда произносится как “скази”, а это более подходящий нам протокол, который позволяет использовать диски другого компьютера как свои собственные. Создавая на них разделы, форматируя и производя абсолютно любые операции как будто эти диски полностью свои.

В чем особенность протокола SCSI, и почему нам не подходит SMB. Дело в том что сетевые шары никак нельзя объединить в единое хранилище, а вот благодаря SCSI мы можем перекинуть диски с нескольких NAS на один компьютер и создать из них RAID. Тем самым получиться простейший вариант единого хранилища, который поможет нам понять основы сетей SAN.

SCSI состоит из двух элементов. SCSI Target – цель, под целью понимают те диски которые будут доступны для передачи на другой компьютер. И SCSI Initiator – инициатор, эта служба подключает на свой компьютер диски из указанной цели.

Для сбора простейшего SAN я буду использовать Windows Server 2012. Понадобятся две машины. У одной мы будет забирать диски, и на вторую их цеплять.

Настройка SCSI Target:

Сначала нам необходимо установить сервер целей. Ставится он только на те файловые сервера диски которых мы хотим передать клиентам, на клиента ставить цель не нужно. Для установки проделываем несколько простых шагов:

  1. Заходим в диспетчер серверов (стартует автоматически при входе в систему);
  2. Нажимаем кнопочку Добавить роли и компоненты.
  3. В открывшемся Мастере добавления ролей и компонентов щелкаем Далее до тех пор пока не дойдет до раздела Роли сервера;
  4. В окошке выборе ролей находим пункт Файловые службы и службы хранилища, в нем Файловые службы и службы iSCSI, и в нем уже выбираем роль Сервер цели iSCSI. В открывшемся окошке щелкаем кнопочки Добавить роли.
  5. В разделе компоненты, по желанию, можно выбрать Служба iSNS сервера. Она служит для централизованного управления службами iSCSI.
  6. Доходим до конца мастера и нажимаем кнопку Установить.

Теперь приступим к настройке. Все так же несколько простых шагов:

  1. Заходим в Диспетчер серверов, слева находим новую закладку Файловые службы и службы хранилища, а в ней закладку iSCSI.
  2. Справа сверху находим раскрывающийся список Задачи, а в нем пункт Создать виртуальный диск iSCSI. Откроется просто и понятный мастер.
  3. В Мастере создания виртуальных дисков iSCSI вводим следующие параметры, по разделам:
    1. Расположение виртуального диска - здесь мы выбираем в каком месте он сохранит образ виртуального диска с которым мы будем дальше работать. Образ имеет всем знакомое расширение VHD.
    2. Имя виртуального диска – имя как будет называться наш файл, и описание если необходимо.
    3. Размер виртуального диска iSCSI – вводим размер нашего виртуального диска.
    4. Цель iSCSI – Это что то вроде точки доступа к которой будут цепляться инициаторы для добавления диска. На этом этапе нужно выбрать имеющуюся цель, но так как цели пока нет, выбираем Новая цель iSCSI.
    5. Имя цели доступа – вводим имя для создаваемой цели, и описание если необходимо.
    6. Серверы доступа - здесь нам надо указать какие инициаторы имеют право подключаться к этой машине. Щелкаем кнопочку Добавить, в появившемся окне выбираем пункт Ввести значение для выбранного типа, в раскрывающимся списке выбираем IP адрес. И вводим IP адреса компьютера на который мы будем перекидывать диски.
    7. Включение службы проверки подлинности – тут для опытных сис. администраторов все понятно, остальные могут пропустить этот пункт.
    8. Подтверждение – проверяем все что мы ввели, и нажимаем кнопочку Создать.
  4. Вот вообщем то и вся настройка. В Диспетчере серверов в разделе iSCSI должна появиться информация о наших дисках и целях, а также информация по их состоянию.

Настройка SCSI Initiator:

Инициатор устанавливать не надо, он предустановлен во всех версиях Windows. Настройка инициатора еще проще, и на всех, Windows даже не серверных, выполняется одинаково:

  1. Нажимаем на кнопку Пуск, или то что вместо нее в новых Windows, и набираем на клавиатуре iscsi.
  2. В появившемся списке выбираем Инициатор iSCSI, при первом запуске появиться окошко с сообщением о необходимости запустить службу, нажимаем Да.
  3. Далее в открывшемся окне Инициатор iSCSI на вкладке Конечные объекты, в группе быстрое подключение вводи IP адрес нашей цели и щелкаем кнопочку Быстрое подключение… .
  4. В появившемся окошке быстрое подключение должно отображаться имя нашей цели iSCSI.
  5. Нажимаем кнопку Готово. В окне Инициатор iSCSI на вкладке Конечные объекты в группе обнаруженные конечные объекты должна появиться наша цель и ее статус.
  6. Вообщем то и все. Теперь мы можем зайти в диспетчер Управление дисками и найти там наш подключенный виртуальный диск.

Осталось только подключить диск к системе, создать на нем раздел и отформатировать. Это делается только один раз на одном компьютере. При подключении другого инициатора к этой цели все разделы и файловые системы уже будут доступны.

Это и есть простейший вариант сети SAN с единым хранилищем. Пока оно бесполезное, но зато теперь мы знаем как работает SCSI. Основа почти всех возможных вариантов сетей SAN.

Теперь встает вопрос как же нам наращивать объем этого хранилища. А ответ вообщем то прост, подключить еще несколько серверов с целями на инициатор.

Теперь когда когда в системе есть много дисков, мы можем сделать из них RAID массив. А лучше Пул. На самом деле RAID массив нельзя собрать в кластере, и он не такой гибкий и удобный как пул. А почему мы не можем обойтись без кластера рассмотрим немного позже.

Теперь когда у нас есть масштабируемый и единый массив дисков, встает вопрос как наращивать скорость этого массива. И тут у нас есть два варианта. Первый, самый простой, сделать так чтобы в машине инициатора было очень много мощных сетевых карт которые и будут раздавать файлы пользователям.

Но к сожалению такая схема имеет много минусов. Во первых ее масштабируемость сильно ограничена количеством и скоростью сетевых карт которые в нее влезут. В один прекрасный момент настанет время когда и 7-ми 10 гигабитных сетевых карт будет не хватать. Во вторых такая схема имеет единую точку отказа. В виде единого раздающего сервера.

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

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

Но тут, в Windows варианте, нас ждет большая проблема. Цель участвующий в массиве можно подключить только к одному инициатору. Цель которая не участвует в массиве можно подключить к нескольким инициаторам, и каждый инициатор будет видеть его как нормальный диск, но есть одна проблема ставящий крест на этой схеме. При записи файлов на диск каждый инициатор будет думать что только он владеет диском и только он имеет право его использовать. В итоге инициаторы не будут видеть файлы друг друга, и даже хуже того, переписывать блоки чужого инициатора своими блоками. Проблема тут в файловой системе, ни NTFS, ни FAT, ни ReFS не являются кластерными файловыми система, а следовательно один диск можно подключить только к одному инициатору. Диски с кластерными ФС можно подключать сразу к нескольким инициаторам, в этом их главное отличие. Но Windows к сожалению кластерных ФС не знает, но это еще не ставит крест на Windows как платформы для построения хранилища, чуть позже мы рассмотрим как же обойти эти ограничения.

К счастью куда лучше дела обстоят у Linux. Там таких систем предостаточно, а кроме того они еще бесплатны, гораздо более мощные и масштабируемые чем в Windows.

Но прежде чем приступить к построению кластерного хранилища рассмотрим варианты на каких протоколах и сетях передачи мы можем его построить.

 

Часть 2. Железный SAN. Варианты протоколов.

Теперь давайте разберемся какие же способы построения SAN существует. Для этого посмотрим существующие протоколы для передачи данных.

 

  • Ethernet - технология пакетной передачи данных в основном для локальных сетей LAN, это то с чем мы сталкиваемся каждый день и представлен в любом компьютере. Представлен в основном Ethernet картой с портом RJ-45. Поверх него работает TCP/IP. А поверх TCP/IP уже работает известная нам SMB и iSCSI.
  • SCSI - технология для физического подключения и передачи данных между компьютерами и периферийными устройствами. В голом виде уже морально устарела. Представлен специальными картами расширения SCSI.
  • Fibre Channel – протокол для высокоскоростной передачи данных. Отличается от Ethernet тем что он ориентирован и оптимизирован исключительно на передачу данных блочных устройств (дисков, устройств хранения). За счет того что исключено все лишнее сильно возрастает производительность и уменьшается время доступа к данным. Внутри у него находиться SCSI и по сути является его логическим развитием. Представлен специальной картой расширения, HBA адаптером. Объединяется в сеть при помощи FC коммутаторов.
  • Fibre Channel over Ethernet – как можно понять обычный FC только работающий по сети Ethernet. Сделано это для объединения и удешевления суммарных затрат на построение сети. Но и время доступа к данным значительно возрастает. Представлен специальным HBA адаптером с поддержкой этой технологии. В сеть объединяется при помощи обыкновенного Ethernet коммутатора с поддержкой этой технологии.
  • InfiniBand - а эта уже целая шина, аналогичная PCI Express, на которой уже может базироваться много важных протоколов. Это совсем молодая технология, призванная объединить и упростить коммутацию, за счет объединения всех сетей в единую. Внутри находятся сразу пакет протоколов, но рассмотрим только интересные нам. IP over InfiniBand – как понятно из названия все тот же TCP/IP. RDMA – протокол прямого доступа к памяти другого компьютера, для нас мало интересен в голом виде. SCSI RDMA Protocol – а вот это уже интересно, через RDMA можно захватить и данные с блочного устройства. InfiniBand представлен платами расширения HCA. Объединяется в сеть при помощи InfiniBand коммутаторов.

Теперь когда у нас есть понимание какие протоколы вообще существуют и как они устроены, мы можем приступить к созданию по настоящему мощного кластерного хранилища.

 

Часть 3. Программное объединения SAN в единое хранилище.

Вариант 1. Windows Failover Cluster

У Windows есть проблема, на одну цель можно подключить только один инициатор. Казалось бы ситуация безнадежная и можно забыть про Windows для кластерного хранилища. Но на самом деле есть решение. Достаточно поднять Отказоустойчивый кластер, который будут обслуживать несколько компьютеров, и уже на этот кластер прицеплять диски и создавать в нем пул с дисками.

Но к сожалению у этого способа есть очень много минусов, поэтому рассмотрим этот вариант лишь поверхностно. Для тех кто желает более детально ознакомиться могут найти статьи в поисковиках по запросу “Clustered Storage Space Windows“. Проблема у этого решения в слишком высоких требованиях к оборудованию, и это при том что масштабируемость такого решения подойдет разве что малым, максимум средним предприятиям.

Этапы построения выглядят следующим образом:

  1. Если вне кластера пул можно создать из любого устройства, хоть флешки, то в кластере исключительно из дисков SAS;
  2. Все диски SAS должны быть подключены ко всем узлам кластера, для этого необходим протокол FC, с соответствующим железом;
  3. Железо должно соответствовать очень высоким требованиям, в частности к стандартам, времени доступа и откликам;
  4. Кластер это всего лишь часть от всей сетевой инфраструктуры, поэтому так же должны быть настроенный домен и dns сервер, все узлы будующего кластера должны быть введены в домен.
  5. На всех узлах кластера должна быть установлена служба Отказоустойчивый кластер.
  6. Далее от имени администратора домена, на любом из будущих узлов кластера, запускаем Диспетчер отказоустойчивых серверов.
  7. В диспетчере находим пункт создать кластер, и следуем по инструкциям мастера.
  8. Вводим имена узлов которые будут обслуживать кластер.
  9. На определенном этапе будут произведены тесты пригодности оборудования для кластерной роли. Тут абсолютно все тесты должны быть отмечены зелеными значками. В случае наличия красных кластер просто не соберется, в случае желтых будут сбои при работе. Тестов очень много, но все условия должны быть выполнены.
  10. Когда кластер соберется откроется консоль управления кластером, очень похожая на консоль управления сервером.
  11. В этой консоли идем в раздел с пулами, и создаем там наш пул, в пуле виртуальный диск. И уже этот виртуальный диск расшаривается для общего доступа.

А теперь о недостатках и почему этот кластер можно посоветовать лишь врагу:

  1. Огромная стоимость инфраструктуры, мало того что диски SAS стоят много дороже чем SATA, так к ним еще и FC подавай.
  2. Кластер на самом деле не Отказоустойчивый, а Кластер на отказ. Т.е. задачу выполняет только один из узлов кластера, другие задействуются только в случае если первый вышел из строя.
  3. Что бы все узлы кластера одновременно работали, необходимо настроить балансировщик нагрузки. В таком случае службы основанные на TCP/IP можно будет распарралелить между всеми узлами. Все остальные службы все равно будут работать на отказ.
  4. Масштабируемость такого кластера весьма спорная, да его можно нарастить по объему, но имеющийся том нельзя расширить, так как в кластере нельзя создавать тонкие диски, а следовательно придется создавать новый том и отдельную шару.
  5. Массив уровня 5 не доступен в кластере, доступны только 0 и 1. Следовательно придется либо терять объем или надежность, выбирая между массивами.
  6. В виду особенности архитектуры узел кластера не может быть файловым сервером, а стало быть опять большие потери на количестве обслуживающих серверов.
  7. Максимально количество узлов, которые могут обслуживать кластер на Server 2012, всего лишь 63.
  8. и еще много страшных пунктов…

Все перечисленные недостатки может быть и являются несущественными, или даже моими придирками, если бы не было других решений, и под Windows их действительно нет. Но к счастью есть еще Linux в котором это делается мало того что проще, так еще и бесплатно и на любом железе.

 

Вариант 2. Распределенные параллельные файловые системы с защитой от сбоев. На примере Gluster FS.

Существует большой выбор такого рода файловых систем GlusterFS, Lustre, Ceph, GPFS, Google FS, MooseFS, MogileFS, POHMELFS и мн. др. И к счастью большая часть из них бесплатна и даже OpenSource. Но есть и один недостаток, как мы выяснили ранее работают они только под Linux.

Чтобы понять как они работают поднимем одну из них. Самая простая и народно любимая, при том же одна из самых мощных это GlusterFS. Самое сложное в его настройке оказалось правильно подобрать дистрибутив. Для этих целей было перепробовано более 10 дистрибутивов OpenSuse 12 и 11, SLES 11, Ubuntu 10 и 12, Fedora 16, CentOS 5 и 6 и др. На всех этих дистрибутивах она отказывалась толком работать. То собраться не может, то зависает напрочь, если использовать более 3 серверов, то скорости не дает. И только на старом добром Red Hat Enterprese Linux (RHEL) версии 5 она заводиться с пол оборота и исправно работает при больших нагрузках.

Для GlusterFS совершенно не требуется какого либо специального железа. Архитектура так же разделена на серверную и клиентскую часть. Работает он либо по Ethernet, либо по Infiniband. Диски могут быть абсолютно любые. Конфигурация компьютеров тоже может быть произвольная. Вместо SCSI для получения файлов с диска используется Linux сервис Fuse. Кроме того GlusterFS абсолютно бесплатный и даже OpenSource. А вся настройка происходит буквально за 7 простых строчек с командами. Я для примера буду использовать GlusterFS версии 3.3.1.

Установка GlusterFS на файловые сервера:

Для начала устанавливаем RHEL 5 на файловые сервера. Во время установки можно не вводить серийный номер, нас интересует только его бесплатная часть. Также необходимо выбрать все пакеты разработки в разделе Development (для опытных только gcc и ядро).

Теперь необходимо до установить пакет FUSE. По умолчанию он не идет на диске с RHEL, поэтому я воспользуюсь поиском по rpm.pbone.net для RHEL 5. Пакет называется fuse-2.7.4-1.el5.rf.x86_64.rpm. Скачиваем и устанавливаем.

wget ftp://ftp.pbone.net/mirror/ftp.freshrpms.net/pub/freshrpms/pub/dag/redhat/el5/en/x86_64/RPMS.dag/fuse-2.7.4-1.el5.rf.x86_64.rpm

rpm -i fuse-2.7.4-1.el5.rf.x86_64.rpm

Теперь настало время установить сам GlusterFS. Для этого достаточно зайти на официальный сайт и посмотреть адрес репозитория для RHEL. Прописываем этот адрес в список репозиториев, после чего станут доступны пакеты GlusterFS. Устанавливаем пакеты glusterfs, glusterfs-fuse, glusterfs-server. Для Infiniband понадобиться еще пакет glusterfs-rdma.

wget http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/EPEL.repo/glusterfs-epel.repo

cp glusterfs-epel.repo /etc/yum.repos.d/

yum install -y glusterfs glusterfs-fuse glusterfs-server

После установки необходимо немного подправить файл конфигурации. Располагается он по адресу /etc/glustefs/glusterd.vol. Во первых необходимо в строчке option transport-type socket,rdma удалить слово RDMA, что бы в логах через строчку не было сообщение об отсутствии Infiniband. Также в строчках option transport.socket.keepalive-time 10 и option transport.socket.keepalive-interval 2 необходимо добавить по два нуля. Это время отклика в миллисекундах, если узел не ответить за заданное время, он будет считаться сломанным. Для таких показателей железо должно быть очень высокого качества, а так как не у всех такое есть увеличиваем эти параметр. В итоге файл должен иметь следующий вид:

volume management
type mgmt/glusterd
option working-directory /var/lib/glusterd
option transport-type socket
option transport.socket.keepalive-time 1000
option transport.socket.keepalive-interval 200
option transport.socket.read-fail-log off
end-volume

или для любителей командной строки вбить:

cat > /etc/glusterfs/glusterd.vol<< EOF
volume management
type mgmt/glusterd
option working-directory /var/lib/glusterd
option transport-type socket
option transport.socket.keepalive-time 1000
option transport.socket.keepalive-interval 200
option transport.socket.read-fail-log off
end-volume
EOF

Осталось только запустить сервис серверной части командой

service glusterd start

Установка завершена. Чтобы каждый сервер не настраивать постоянно вручную, все команды можно свести к одному скрипту, который можно просто скопировать в консоль и все само настроиться

cd
cd /tmp

wget ftp://ftp.pbone.net/mirror/ftp.freshrpms.net/pub/freshrpms/pub/dag/redhat/el5/en/x86_64/RPMS.dag/fuse-2.7.4-1.el5.rf.x86_64.rpm

rpm -i fuse-2.7.4-1.el5.rf.x86_64.rpm

wget http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/EPEL.repo/glusterfs-epel.repo

cp glusterfs-epel.repo /etc/yum.repos.d/

yum install -y glusterfs glusterfs-fuse glusterfs-server

cat > /etc/glusterfs/glusterd.vol<< EOF
volume management
type mgmt/glusterd
option working-directory /var/lib/glusterd
option transport-type socket
option transport.socket.keepalive-time 1000
option transport.socket.keepalive-interval 200
option transport.socket.read-fail-log off
end-volume
EOF

service glusterd start

cd
mkdir /gluster
mkdir /gluster/brick01

 

Достаточно скопировать их в консоль сразу после установки RHEL и GlusterFS автоматически установится, и сделает предварительные настройки.

 

Настройка серверной части:

Для начало на каждом узле файлового хранилища создадим папку, которая будет использоваться для организации хранилища. У меня это будут /gluster/brick01 на первом сервере, /gluster/brick02 на втором сервере и т.д. Главное чтобы имена папок у всех серверов были разные.

Далее на одном из узлов кластера, он будет называться мастером, выполняем команды по настройке GlusterFS.

gluster peer probe IP

При помощи этой команды происходит проверка другого узла на наличие GlusterFS и подключение его к общему кластеру. Проверить статус узлов кластера можно командой gluster peer status. Если при добавлении узлов произошла ошибка или вы просто испортили конфигурацию можно просто из бракованного узла удалить все настройки и еще раз попробовать добавить узел. Хранятся настройки в папке /var/lib/glusterd.

Теперь необходимо создать диск в кластере, делается это командой

gluster volume create VOL_NAME IP1:/patch1 IP2:/patch2 IP3:/patch3

Здесь мы вводим название нашего диска, а также какие папки на каких серверах будут использоваться для обслуживания кластера. После имени диска можно задать тип массива который будет создан из папок. Всего вариантов массивов доступно около 9 штук. В документации все они детально описаны. Дисков так же может быть несколько, с разным типом массивов.

Осталось только сделать наш диск активным

gluster volume start VOL_NAME

Вот вообще то и вся настройка. Всего три строчки. И у вас мощное кластерное хранилище. Проверить статус диска можно командой gluster volume info. Сервера и объем можно добавлять прям на ходу командой gluster volume add VOL_NAME IP:/patch. Если в кластер добавлялись новые машины или по другой причине произошла разбалансировка, выполняется команда gluster volume rebalance VOL_NAME start.

 

Настройка клиентской части:

Здесь на самом деле все еще проще. Точно так же как и на серверной части на клиентскую машину выполняется установка GlusterFS. За исключением того что пакет gluster-server можно не устанавливать и сервис glusterd можно не запускать.

Для начала понадобится папка при обращение к которой нам будет выдано все содержимое кластера. Я для этого создал /gluster/storage. А дальше выполняется простая команда

mount -t glusterfs IP:/VOL_NAME /gluster/storage

Вообщем то и все. Теперь при обращении к папке /gluster/storage клиенту будет выдано все содержимое кластера. При записи в эту папку файлы будут равномерно распределены по узлам кластера. Масштабируемость такого кластера ограничивается несколькими петабайтами данных, скорости несколькими терабитами в секунду.

Linux пользователи могут напрямую подключаться к кластеру или использовать протокол NFS. Windows пользователям файлы необходимо раздавать по протоколу SMB. Благодаря архитектуре каждый узел кластера также может быть и клиентом, что позволяет сильно с экономить на серверах. Но надо не забывать что SAN должен быть вынесена в отдельную сеть для лучшей производительности.

Кроме GlusterFS хочется отметить еще и Lustre. Настройка ее не намного сложнее GlusteFS, а отличается тем что метаданные вынесены на отдельный сервер, и клиент уже не опрашивает все сервера в поисках файлов, а обращается к серверу метаданных за файлом, который уже и сообщает клиенту где храниться файл. Благодаря этому Lustre является самым производительным и крупно масштабируемым решением из всех существующих. Чего стоит только статистика, в ТОП-30 супер компьютеров Lustre установлена более чем на половине, включая самый топовый. Также такие компании как HP, DELL, CRAY, SGI и другие поставляют люстру в своих масштабируемых файловых хранилищах.

 

Вариант 3. Облачная инфраструктура

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

Везде трубят что облачность инфраструктуры способна сокращать ее стоимость в разы. Так давайте же разберемся за счет чего это происходит. Допустим у нас обычная, не облачная инфраструктура. В Этой инфраструктуре должны быть: 1. Файловые сервера, цена каждого от 130 т.р., 2. Рендер нода, цена 2*XEON E5 от 120 т.р., 3. Компьютеры пользователей, цена от 40 т.р., без учета мониторов. Сумма этих трех компьютеров составляет почти 300 т.р. А теперь смотрим кто из них как используется. В файловом сервере простаивают процессор и память, в рендер ноде винчестеры, у пользователя винчестеры, ядра и память.

Так вот облачная инфраструктура позволяет задействовать все мощности компьютера целиком, а не частями. Т.е. вместо трех машин за 300 т.р. можно купить одну на 150 т.р. и она будет выполнять роль файлового хранилища, вычислительного узла и рабочей станции сотрудника. Тем самым мы в 2 раза уже экономим на серверах, и еще столько же на инфраструктуре и поддержке, общее снижение затрат составляет более чем в 3 раза.

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

  1. Должно поддерживаться проброс видеокарты (PCI Passtrough) в виртуальную машину. Иначе сотрудник не сможет нормально работать если у него все будет тормозить.
  2. Должно быть доступно резервирование ресурсов для каждой машины и настраиваемая система приоритетов. Нашему файловому серверу нужно хоть немного от частоты процессора для обслуживания файлового сервера, надо задать ему этот гарантированный объем, а также максимальный приоритет перед другими участниками облака на этой машине. Пользователю тоже необходимо задать гарантированный объем процессора, памяти и скоростей сети и хранилища, а также возможность использования всех ресурсов сервера с приоритетом над рендер нодой. Ну и рендер ноде, то что осталось.
  3. Облако должно поддерживать единое кластерное хранилище.

Что получается в итоге, файловое хранилище работает с максимальным приоритетом, а за счет резервирования ему всегда будет доступен определенный объем ресурсов. Пользователь также работает в минимальном наборе ресурсов и никто на него не полезет, но если пользователю на сложную операцию понадобиться больше двух ядер, облако в считанные миллисекунды отнимет их у рендер ноды. И рендер нода работает всегда, в итоге нету простоев оставшихся ресурсов никогда.

ПРОДОЛЖЕНИЕ =>

782 0 850 21
11
2013-03-29
Статья больше техническая и больше подходит для выкладывания на habrahabr.ru как мне кажется. Ну а так спасибо за статью, даже понял некоторые нюансы.
2013-03-29
Статья не оправдала ожиданий. Думал тут будут советы для начинающих студий, а тут только о настройке серверов и хранилищ... Правильнее назвать статью - "Настройка файловых хранилищ".
2013-03-29
статья неплохая, как раз сейчас интересуюсь сетевыми решениями. Да и многие, сечас задаются вопрсоом, как можно использвоать возможности сети. За статью и труд отдельное спасибо и хоршая оценка ;) :)
2013-03-30
[quote=Pit3ds] больше подходит для выкладывания на habrahabr.ru как мне кажется [/quote] Что за глупости, у нас что тут технарей нет и людей способных это оценить. Автор, глубочайший респект, большой труд проделан, огромная польза всем кого интересует эта тема, да и просто интересно почитать. Еще раз большое спасибо.
2013-03-30
[quote=Pit3ds] выкладывания на habrahabr.ru как мне кажется [/quote] На хабрахабре несколько другая аудитория, а тут именно киношники, это в первую очередь для нас и для своих. Во вторых там слишком суровые и эгоэстичные условия публикации для такого рода статей. Особенно учитывая количество ошибок =)))) [quote=dimson3d] За статью и труд отдельное спасибо и хоршая оценка ;) :) [/quote] И тебе спасибо ;) Правда от оценок никакого толка кроме кармы =))
2013-03-30
1. Часть про файловые хранилишы хороша! Остальное уже несколько хуже... 2. Про проектное управление - скажем так, я не согласен! "И поэтому большинство руководителей предпочитают вести все свои записи в простых таблицах Excell" Например Cerebro кстати используют гдето в 70 студиях в СНГ - то есть почти во всех :) В зарубежных больше shotgun / ftrack - Формула KPI это просто чума без коментариев :) - Про наглядность / стадии, вот например скриншот таск таркинга в Cerebro [img]https://cinesoft.zendesk.com/attachments/token/ayi5mrmt7shdb6s/?name=tracking.PNG[/img]
2013-03-30
[quote=GeorgeThreeD] Статья не оправдала ожиданий. Думал тут будут советы для начинающих студий [/quote] Вот две хорошие на этот счет: http://polycloud.ru/blog/int/75.html http://polycloud.ru/blog/int/77.html
2013-03-31
Лабег привет) Очень интересно было, спасибо)
2013-03-31
[quote=Wasteland] Лабег привет) [/quote] Привет =)) Давненько не виделись =)) [quote=Константин Харитонов] 2. Про проектное управление - скажем так, я не согласен! [/quote] Константин я понимаю что вы опытный человек, живете своим делом, и тесно сотрудничаете с самыми пропиареными российскими студиями, но я останусь при своем мнении =)) И хорошим поводом остаться на своем мнении являются как раз те две ссылки что вы дали. 70% пунктов с проблемами связаны именно с неверной оценкой производства. И KPI в моих планах был очень удачным решением. Благодаря которому я точно мог рассчитать сколько времени моим отделам придется затратить. Благодаря чему мои отделы отрабатывали точно по плану и в срок. Вообще раздел 3 и 4 был дан в нагрузку. И в очень лаконичном виде. Там много чего не досказано, в частности про то почему у вас 4-я цифра 0 в номере сцены. PS: Вижу церебро сильно продвинулся с тех пор как я последний раз туда заглядывал =)
2013-03-31
[quote=LabEG]...тесно сотрудничаете с самыми пропиареными российскими студиями...[/quote] В СНГ студии практический не пиаряться (или делают это очень редко, на cgevent'е напримре :) ), просто некоторые компании хорошие, а другие похуже :) [quote=LabEG]И KPI в моих планах был очень удачным решением.[/quote] Есть вы делаете ротоскопинг или конвернтацию в стерео - то есть чтото простое и предсказуемое, то ваш метод предсказывания времени по длительности шота с учетом коф. сложности должен работать! В любых задачах связынах с производством 3D или сложном композе - в предсказаниях помогает только опыт суперевайзера! То есть по мне методы оценки KPI для планирования/предсказания - мало применимы, а вот в методы аналитики (то есть оценки постфактум), я очень даже верю и пропагандирую! [quote=LabEG] PS: Вижу церебро сильно продвинулся с тех пор как я последний раз туда заглядывал =) [/quote] Спасибо :)
2013-07-21
Статья хорошая но SCSI для высоко нагруженных систем не подходит априори так как загружается сетевой канал для этих целей использую Fiber Chanel причем уже лет 5 и одна EVA может прокачать трафик в 4000 пользователей без проблем обрабатывающих графику на одном массиве + когда собраться кластерные массивы под разные типы данных (видео, графику, тексты, и т.д.) используют различные типы RAID массивов и самое главное размеры кластеров ибо контроллерам проще отдать одним куском 128 килобайтный кластер видео файла нежели искать и собирать его в стандартных размерах в то же время мелкий текстовый док обязан храниться в логических массивах малых размеров. А статья классная !
RENDER.RU