Закрытость документации и ПО (доступность только заказчикам / партнёрам) - достаточно распространённая практика среди аппаратных вендоров оборудования А-класса по всему миру. И общей тенденции на увеличение открытости, к сожалению, не заметно.
Вы правы, для высокоёмких накопителей рекомендуется использовать RAID6. К сожалению, мы не успели протестировать все желаемые сценарии: по RAID-ам, профилям нагрузки и размерам блоков. При этом, надеюсь, что и фактически полученные нами цифры для RAID5 полезны и опытный глаз путём экстраполяции может получить представление и оценку (в том числе для RAID6).
Конечно, при выборе локаций для хранения резервных копий нужно считать TCO и смотреть, с чем сравниваем. Например, если сравнивать с дисковым хранением, то зачастую разместить копии в облаке все же выгоднее. Плюс мы сразу закроем задачи отчуждаемости бэкапов.
Многое уже сказано выше и что-то я могу поддержать.
Действительно, мы рассматриваем корпоративные и enterprise-среды, где все же потеря данных зачастую является недопустимой. И для понимания стратегии защиты, как я уже написал, требуется классифицировать свои информационные системы по критичности, чтобы понимать, как часто их бэкапить (если бэкапить вообще) и сколько времени хранить.
При классификации, конечно же, помогает оценка влияния потери данных на бизнес. Если совсем грубо - сколько компания теряет за каждый час простоя информационной системы или как повлияет на бизнес невосстановимая утеря данных (где-то это может быть сравнимо с потерей бизнеса в целом).
Тут есть единственный верный способ. Нужно определить:
Какие данные для вас наиболее критичны
Какие финансовые и/или нефинансовые потери (репутация, простой и т.п.) вы понесете в случае их утраты. В некоторых случаях это может быть потеря всего бизнеса
И дальше сопоставить со стоимостью организации правильного резервного копирования
Критичные данные в любом случае нужно защищать. Способов великое множество, и действительно все зависит от задач и возможностей. Скопировать данные на другой диск или на сетевую шару другого сервера — это уже бэкап. Многие публичные провайдеры раздают небольшое количество облачного пространства бесплатно. Можно организовать копирование данных к ним.
Если нет бюджета на специализированный софт, то можно использовать скрипты, встроенный функционал приложений и СУБД. Можно легко нагуглить Open source приложения с большим количеством агентов и возможностей для организации бэкапов, те же Bacula и Bareos.
Нюансам сертификации ФСТЭК я посвятил в статье отдельный абзац
Однако сертифицированная версия будет менее функциональной (процесс сертификации долгий, поэтому, как правило, выходит уже новый релиз с новыми фичами), поэтому обычная версия в сочетании с наложенными СЗИ — более функциональное решение.
По словам вендора, версию 4.1 уже готовят к сертификации. Но повторюсь, временной лаг в выходе сертифицированной версии продукта — это данность для всех российских продуктов.
Что касается ограничений, справедливо, забыл упомянуть об этом в статье. Спасибо за комментарий! В любом случае, вендор прописал все имеющиеся ограничения в своей документации, а значит — в курсе необходимых доработок и уже работает над ними.
Да, действительно, прайс закрытый. Однако замечу, что такая практика — не редкость среди вендоров. Если необходимо, рекомендую обратиться к вендору напрямую info@orionsoft.ru или к нам как к партнеру alzotov@k2.tech. Оперативно ответим, все посчитаем.
Про 95% процентов — это заявление вендора. Я же в статье обозначил, что цифра в 95% взята не от всех возможностей VMware, а от реальных потребностей заказчиков в функциональности платформы. В нашей практике были заказчики, которые закупили VMware, но использовали лишь самый базовый функционал. А это сейчас может обеспечить совершенно любая платформа виртуализации.
Что касается кейса с отказом локального диска, то какое-то время платформа жить будет. Но уже с заметными аномалиями, которые можно отследить и своевременно отредактировать, если системы мониторинга настроены должным образом. Для всех платформ есть лучшие практики, которые помогают как следить за работой системы в целом, так и своевременно обновлять систему.
В целом, при выборе решения на замену VMware стоит учитывать тот факт, что точно так же, как в VMware, в других решениях работать не будет. Это касается всех решений по виртуализации, доступных на российском рынке.
Действительно, все зависит от задач. Если вас и пользователей ресурсов, работающих в виртуальных машинах, все устраивает, то все верно. При проектировании виртуализации учитываются все те же принципы, что и при построения информационных систем. Выбранное решение должно выполнять возлагаемые на нее задачи. Решение должно быть надежным, отказоустойчивым, масштабируемым, безопасным, и, самое главное, хорошо задокументированным. Если получается все это обеспечить своими силами, отлично! Но стоит помнить, что заказчики — особенно уровня enterprise — все же отдают предпочтение готовым решениям с хорошей, долгосрочной, гарантируемой поддержкой и развитием.
Верно подмечено. Для построения хостинга одной лишь виртуализации недостаточно. Тут нужен комплексный подход. В архитектуре построения хостинга учитывать придётся много всего: это взаимодействие с разными площадками, особенности, возможности и совместимости виртуализации, биллинга, оркестратора, интерфейсов для пользователей, операторов, администраторов, систем резервного копирования, систем сетевого взаимодействия, систем ИБ, взаимодействие с аппаратными ресурсами и их мониторинга. Все между собой должно быть совместимо. Большие хостинговые компании предпочитают отдавать клиентские ресурсы в виде контейнеров, а не полноценными виртуалками. Для этих целей больше подойдут продукты на основе OpenStack/OpenShift.
На мой взгляд, продукт выглядит достаточно зрело. Мы проверили его в довольно крупных инсталляциях, zVirt показал себя достойно. О чем и рассказал в статье... Но вообще рекомендую самостоятельно обратиться к вендору, протестировать и сформировать своё мнение.
Прекрасно вас понимаю! Хотя мы тестируем оборудование на постоянной основе, но так много, как в последние годы, мы не тестировали никогда. И за это время мы тоже много чего повстречали и увидели. Возможно, даже напишу про это отдельную статью
Я уже довольно давно пишу обзорные статьи на российские решения и под каждой такой статьей вижу очень похожие вопросы :)
Что на это можно ответить в целом? Сейчас мировой рынок устроен так, что невозможно все компоненты вычислительного оборудования производить самостоятельно, в рамках одной страны. В таких условиях главные преимущества российских производителей — это логичная, понятная и предсказуемая схема поставки, техническое сопровождение, а также ориентация именно на наши компании и наших пользователей.
А если в частности, то в своей статье я специально дал ссылку на Хабра-пост от представителя "Инферита", где он достаточно подробно рассказал об этапах проектирования и сборки оборудования.
Да, кажется, SNMP и Syslog плотно ассоциируются у всех производителей как дефолтные источники мониторинговых данных. Те же HPE и Dell предлагают доступ через RestAPI, но здесь у нас база на Supermicro и все достаточно стандартно.
SNMP устарел, но у нас была задача в этой статье показать возможности СХД, что мы и сделали :)
Да, действительно, для решения задач виртуализации есть разные варианты. В целом, мы работаем практически со всеми вендорами на рынке (с тем же Брестом у нас есть проекты). И заказчикам мы внедряем решения, исходя из их запросов и планов развития.
В данном конкретном проекте в НГУ мы посчитали, что zVirt — это наиболее оптимальное решение с учетом всех обозначенных требований и целей. До этого мы этот продукт внедряли у достаточно большого числа своих заказчиков, поэтому для нас это решение проверенное, стабильное, весьма зрелое. И вендорская поддержка, к слову, тоже есть
Обычно мы используем xCAT, и данный проект не исключение. В инсталляциях с Ubuntu берём MAAS. А в сравнительно небольших кейсах и Ansible вполне достаточно.
Добрый день! Я в целом уже ответил в комментариях, задача стояла собрать решение полностью из отечественных компонентов: это касается как серверов, так и интерконнекта.
И хотел бы дополнить, что даже 0.5 мкс разницы в задержке на передачу сообщений в нашем случае - это целых 50% выигрыша в сравнении с InfiniBand.
Закрытость документации и ПО (доступность только заказчикам / партнёрам) - достаточно распространённая практика среди аппаратных вендоров оборудования А-класса по всему миру. И общей тенденции на увеличение открытости, к сожалению, не заметно.
Вы правы, для высокоёмких накопителей рекомендуется использовать RAID6. К сожалению, мы не успели протестировать все желаемые сценарии: по RAID-ам, профилям нагрузки и размерам блоков. При этом, надеюсь, что и фактически полученные нами цифры для RAID5 полезны и опытный глаз путём экстраполяции может получить представление и оценку (в том числе для RAID6).
Конечно, при выборе локаций для хранения резервных копий нужно считать TCO и смотреть, с чем сравниваем. Например, если сравнивать с дисковым хранением, то зачастую разместить копии в облаке все же выгоднее. Плюс мы сразу закроем задачи отчуждаемости бэкапов.
Многое уже сказано выше и что-то я могу поддержать.
Действительно, мы рассматриваем корпоративные и enterprise-среды, где все же потеря данных зачастую является недопустимой. И для понимания стратегии защиты, как я уже написал, требуется классифицировать свои информационные системы по критичности, чтобы понимать, как часто их бэкапить (если бэкапить вообще) и сколько времени хранить.
При классификации, конечно же, помогает оценка влияния потери данных на бизнес. Если совсем грубо - сколько компания теряет за каждый час простоя информационной системы или как повлияет на бизнес невосстановимая утеря данных (где-то это может быть сравнимо с потерей бизнеса в целом).
Тут есть единственный верный способ. Нужно определить:
Какие данные для вас наиболее критичны
Какие финансовые и/или нефинансовые потери (репутация, простой и т.п.) вы понесете в случае их утраты. В некоторых случаях это может быть потеря всего бизнеса
И дальше сопоставить со стоимостью организации правильного резервного копирования
Критичные данные в любом случае нужно защищать. Способов великое множество, и действительно все зависит от задач и возможностей. Скопировать данные на другой диск или на сетевую шару другого сервера — это уже бэкап. Многие публичные провайдеры раздают небольшое количество облачного пространства бесплатно. Можно организовать копирование данных к ним.
Если нет бюджета на специализированный софт, то можно использовать скрипты, встроенный функционал приложений и СУБД. Можно легко нагуглить Open source приложения с большим количеством агентов и возможностей для организации бэкапов, те же Bacula и Bareos.
Нюансам сертификации ФСТЭК я посвятил в статье отдельный абзац
По словам вендора, версию 4.1 уже готовят к сертификации. Но повторюсь, временной лаг в выходе сертифицированной версии продукта — это данность для всех российских продуктов.
Что касается ограничений, справедливо, забыл упомянуть об этом в статье. Спасибо за комментарий! В любом случае, вендор прописал все имеющиеся ограничения в своей документации, а значит — в курсе необходимых доработок и уже работает над ними.
Да, действительно, прайс закрытый. Однако замечу, что такая практика — не редкость среди вендоров. Если необходимо, рекомендую обратиться к вендору напрямую info@orionsoft.ru или к нам как к партнеру alzotov@k2.tech. Оперативно ответим, все посчитаем.
Про 95% процентов — это заявление вендора. Я же в статье обозначил, что цифра в 95% взята не от всех возможностей VMware, а от реальных потребностей заказчиков в функциональности платформы. В нашей практике были заказчики, которые закупили VMware, но использовали лишь самый базовый функционал. А это сейчас может обеспечить совершенно любая платформа виртуализации.
Что касается кейса с отказом локального диска, то какое-то время платформа жить будет. Но уже с заметными аномалиями, которые можно отследить и своевременно отредактировать, если системы мониторинга настроены должным образом. Для всех платформ есть лучшие практики, которые помогают как следить за работой системы в целом, так и своевременно обновлять систему.
В целом, при выборе решения на замену VMware стоит учитывать тот факт, что точно так же, как в VMware, в других решениях работать не будет. Это касается всех решений по виртуализации, доступных на российском рынке.
Действительно, все зависит от задач. Если вас и пользователей ресурсов, работающих в виртуальных машинах, все устраивает, то все верно. При проектировании виртуализации учитываются все те же принципы, что и при построения информационных систем. Выбранное решение должно выполнять возлагаемые на нее задачи. Решение должно быть надежным, отказоустойчивым, масштабируемым, безопасным, и, самое главное, хорошо задокументированным. Если получается все это обеспечить своими силами, отлично! Но стоит помнить, что заказчики — особенно уровня enterprise — все же отдают предпочтение готовым решениям с хорошей, долгосрочной, гарантируемой поддержкой и развитием.
Верно подмечено. Для построения хостинга одной лишь виртуализации недостаточно. Тут нужен комплексный подход. В архитектуре построения хостинга учитывать придётся много всего: это взаимодействие с разными площадками, особенности, возможности и совместимости виртуализации, биллинга, оркестратора, интерфейсов для пользователей, операторов, администраторов, систем резервного копирования, систем сетевого взаимодействия, систем ИБ, взаимодействие с аппаратными ресурсами и их мониторинга. Все между собой должно быть совместимо. Большие хостинговые компании предпочитают отдавать клиентские ресурсы в виде контейнеров, а не полноценными виртуалками. Для этих целей больше подойдут продукты на основе OpenStack/OpenShift.
На мой взгляд, продукт выглядит достаточно зрело. Мы проверили его в довольно крупных инсталляциях, zVirt показал себя достойно. О чем и рассказал в статье... Но вообще рекомендую самостоятельно обратиться к вендору, протестировать и сформировать своё мнение.
Прекрасно вас понимаю! Хотя мы тестируем оборудование на постоянной основе, но так много, как в последние годы, мы не тестировали никогда. И за это время мы тоже много чего повстречали и увидели. Возможно, даже напишу про это отдельную статью
Я уже довольно давно пишу обзорные статьи на российские решения и под каждой такой статьей вижу очень похожие вопросы :)
Что на это можно ответить в целом? Сейчас мировой рынок устроен так, что невозможно все компоненты вычислительного оборудования производить самостоятельно, в рамках одной страны. В таких условиях главные преимущества российских производителей — это логичная, понятная и предсказуемая схема поставки, техническое сопровождение, а также ориентация именно на наши компании и наших пользователей.
А если в частности, то в своей статье я специально дал ссылку на Хабра-пост от представителя "Инферита", где он достаточно подробно рассказал об этапах проектирования и сборки оборудования.
Да, кажется, SNMP и Syslog плотно ассоциируются у всех производителей как дефолтные источники мониторинговых данных. Те же HPE и Dell предлагают доступ через RestAPI, но здесь у нас база на Supermicro и все достаточно стандартно.
SNMP устарел, но у нас была задача в этой статье показать возможности СХД, что мы и сделали :)
Да, действительно, для решения задач виртуализации есть разные варианты. В целом, мы работаем практически со всеми вендорами на рынке (с тем же Брестом у нас есть проекты). И заказчикам мы внедряем решения, исходя из их запросов и планов развития.
В данном конкретном проекте в НГУ мы посчитали, что zVirt — это наиболее оптимальное решение с учетом всех обозначенных требований и целей. До этого мы этот продукт внедряли у достаточно большого числа своих заказчиков, поэтому для нас это решение проверенное, стабильное, весьма зрелое. И вендорская поддержка, к слову, тоже есть
Обычно мы используем xCAT, и данный проект не исключение. В инсталляциях с Ubuntu берём MAAS. А в сравнительно небольших кейсах и Ansible вполне достаточно.
Имеется в виду Intel Xeon Scalable Gen3
Спасибо вам за комментарий! Тут я полностью согласен, даже немного раскрыл и дополнил идеи в предыдущих комментариях.
Добрый день! Я в целом уже ответил в комментариях, задача стояла собрать решение полностью из отечественных компонентов: это касается как серверов, так и интерконнекта.
И хотел бы дополнить, что даже 0.5 мкс разницы в задержке на передачу сообщений в нашем случае - это целых 50% выигрыша в сравнении с InfiniBand.