Как стать автором
Обновить

Комментарии 6

А почему не ceph? С учётом, что в разных пулах можно использовать разный уровень redundancy (и даже erasure coding), одновременно имея и файловый и объектный доступ, ceph выглядит как очень разумное решение.


При некотором размышлении, можно даже придумать cost-effective migration path из thunderbolt-коробочек в ceph-cluster, без потери оборудования.

Да, собственно, идеи к построению инфраструктуры, приведенные в статье, не являются абсолютными. И ваш подход тоже имеет право на жизнь. Но в реальной жизни грамотные IT спецы в медиа студиях (особенно в малых) встречаются не так уж и часто. Поэтому реализовывать (и поддерживать в последствии) сложные схемы с использованием SDS банально некому. Проще нажать пару кнопок в интерфейсе NAS.

Вы уверены, что ваши nas'ы так уж просты в администрировании? Каким образом сохранность данных обеспечивается? Во времена thunderbolt-коробочек довольно просто — каждая коробочка автономная, и если её уронить из окна, остальные уцелеют. А теперь все данные складывают на одно хранилище, где одно неловкое движение — и вся студия без контента. Полностью.


А защита от неловкого движения… Ну, расскажите мне про disaster recovery с помощью пары кнопок в интерфейсе.

Если студия маленькая и все свои IT проблемы решают сами, то чаще всего используют «коробки» либо централизованный NAS. Вопросы резервирования решают в соответствии со своими «представлениями о прекрасном». Да, NAS Qsan имеют ряд функций, помогающим в работе бэкапа. И, да, большинство такого функционала настраивается парой кнопок.
А вот если студия уже заметных размеров, то и подход в организации IT инфраструктуры доверен соответствующим специалистам. Вариант может быть и как вы предлагаете, и как мы описываем — с участием СХД.

У вас есть какое-нибудь по на железо, без железа
Аля vsa, scaleio, xpenology?

Нет. ПО привязано к «железу».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий