120 пользователь VDI выдаёт 60000 IOPS на запись – это что-то уникальное. Удалось вычислить что действительно создаёт столько нагрузки?
22 IOPS на АРМ в описанных тестах – это дополнительная нагрузка, создаваемая иометром, помимо тех, что создают и другие описанные задачи.
В среднем мы видим по проектам, на дисковую подсистему каждый пользователь генерит по 15-25 IOPS 60/40% R/W. От проекта к проекту цифры естественно разные, но держатся около этих показателей.
Вот для примера скриншоты с реальной системы SimpliVity, расположенной у заказчика под VDI, где создано 216 вм и около 80% из них в среднем активно:
Использование 8170 особенность тестирования, где действительно целью было получить побольше ядер в одном узле.
В реальных проектах, как правильно заметили, чаще всего используем 6148 (новые 6248 только вышли, так что будем в и их закладывать). 4-сокетные серверы ставить не всегда целесообразно, т.к. в итоге получается большой домен отказа, а экономия только в занимаемом пространстве (если сравнивать именно 2U серверы).
Про NVMe диски немного не в тему. В SimpliVity они на данный момент не используются. Да и такого заметного влияния для пользователей они не дадут. А для БД, мегакритичных к задержкам – да.
Вопиющий технический косяк» — на самом деле разумное ограничение, т. к. ноды 4000-й серии содержат в себе Read-Intensive диски.
Если изначально понятно, что ожидается постоянная активная запись 24х7, никто не мешает взять ноды 6000-й серии с Write Intensive дисками, где ничего не лимитируется.
По моральному устареванию и деградации — вопрос спорный. Тем более в первую очередь важно решение бизнес-задач и обеспечение для них отказоустойчивой, гибкой и производительной платформы, чему это решение полностью соответствует.
Карты Teradici предназначены для оффлоада нагрузки протокола PCoIP. Здесь же при тестировании да и в целом в проектах мы используем HDX для Citrix и Blast для VMware.
Intel Optane в рамках самого SimpliVity не используется. Отдельных тестов под это не проводили, да и большого смысла под VDI в этом не видим.
Если не ошибаюсь, когда HPE купили SimpliVity они говорили, что хотят выпилить Omnistack Acccelerator Card и перенести все в софт. Кластер можно создать из двух нод? -Да. Фактически, можно из одной, если использовать конфигурацию 2+1, где две на основной площадки бэкапятся на одну на второй. На картинке в статье медь 10Г? — 10Gb между нодами в одном кластере. Между площадками плохой канал провайдера. Зачем нужна интеграция с vcenter? — для единой консоли управления всей инфраструктурой. Чтобы не плодить консоли. Что будет если один диск SDD\HDD умрет? — HDD восстановится, у нас ссд в рейде, отказ обрабатывается как для диска на уровне контроллера. Если будет потеряна одна нода? — все останется работать на второй. Долго ли ребилд будет в этих случаях? — зависит от используемого объёма. По сути пока не за синхронизируются все данные. Из маркетинга понятно, что все будет хорошо. А с технической точки зрения, какие механизмы включатся? — обычного восстановления RAID или синхронизации нод. Зачем нужна интеграция с vcenter? Какие версии vcenter поддерживаются. — 5.5, 6.0, 6.5. Сколько нужно отдать вычислительных мощностей для SimpliVity? — от 50 ГБ оперативной памяти и больше, зависит от конфигурации. У ребят в филиале по две ноды, сколько нод в ЦО? — тоже две. Будет ли деградация производительности при большом количестве снапшотов? — нет. К примеру в сумме 15 ВМ общим объёмом 1,5 Тб. Нужно будет держать бэкап глубиной в 30 дней, бэкап проходит раз в сутки в ночное время. — можно. Компрессия и дедуп на лету проходят или отложенный механизм? — на лету. Поддерживается ли реплика многие к одному? — да. Интегрируется это решение со сторонними средствами бэкапов и планируется ли? — интегрируется с любым, кто может бэкапить с VMware.
Пока руки не дошли. Хотя у нас даже было пару запросов за прошлый год на proxmox. Но собирали нечто похожее на Red Hat OpenStack Platform + Ceph. Нельзя назвать такой набор полноценной гиперконвергенцией. Но OpenStack платформа дает большие возможности для творчества. И можно прикрутить кучу других сервисов при желании.
Заказчики которые выбирают гиперконвергенцию для филиалов обычно руководствуются задачей упрощения администрирования на месте и возможностью резервного копирования между филиалами (в случае Simplivity). Им нравится что все из одной консоли, причем эта консоль может быть в центральном офисе. На месте не требуется высококвалифицированный сотрудник и решение закрывает сразу несколько задач. Такую задачу можно закрыть по другому и дешевле, но придется пойти на компромисс. Можно привести в пример поездку на работу. Есть несколько вариантов: Общественный транспорт, своя машина или велосипед. Все варианты решают задачу за разные деньги и с разной скоростью. Нельзя сказать что какой-то вариант не правильный. Гиперконвергенция это один из способов решения. Для некоторых это закрытие всех задач сразу, а кто-то наймет выделенного человека, купит писюк с бесплатным гипервизором и будет бекапить скриптами. Все зависит от уровня развития компании.
Если сравнивать со стоимостью Сервера+СХД+Сеть хранения+бекап то выходит выгоднее. К примеру в случае с Simplivity дедупликация позволяет понизить требования к дисковой подсистеме в плане производительности. Понадобится меньше шпинделей для получения целевых показателей. Но иногда выходит дороже. Тогда мы предлагаем заказчику классическое решение с выделенной СХД стартового уровня или SDS. По опыту можно сказать что разброс цен ± 30%. Были случаи когда гиперконвергенция была чуть дороже но заказчик все равно ее выбирал так как ему нравилась простота. Чаще всего во всех проектах у нас нет ультимативности, мы предлагаем заказчикам несколько вариантов на выбор и описываем плюсы и минусы.
Серверы могут быть любые. В данном случае делл, сейчас hpe. Фишка не в серверах, а в софте, который на них работает. В этом и идея гиперконвергенции. Симпливити умеет общее хранилище с дедупликацией и компрессией из локальных дисков, быстрый бэкап между сайтами, DR, централизованное управление. На обычных серверах с локальными дисками. А vrtx — это классические железки
22 IOPS на АРМ в описанных тестах – это дополнительная нагрузка, создаваемая иометром, помимо тех, что создают и другие описанные задачи.
В среднем мы видим по проектам, на дисковую подсистему каждый пользователь генерит по 15-25 IOPS 60/40% R/W. От проекта к проекту цифры естественно разные, но держатся около этих показателей.
Вот для примера скриншоты с реальной системы SimpliVity, расположенной у заказчика под VDI, где создано 216 вм и около 80% из них в среднем активно:
В реальных проектах, как правильно заметили, чаще всего используем 6148 (новые 6248 только вышли, так что будем в и их закладывать). 4-сокетные серверы ставить не всегда целесообразно, т.к. в итоге получается большой домен отказа, а экономия только в занимаемом пространстве (если сравнивать именно 2U серверы).
Про NVMe диски немного не в тему. В SimpliVity они на данный момент не используются. Да и такого заметного влияния для пользователей они не дадут. А для БД, мегакритичных к задержкам – да.
Если изначально понятно, что ожидается постоянная активная запись 24х7, никто не мешает взять ноды 6000-й серии с Write Intensive дисками, где ничего не лимитируется.
Карты Teradici предназначены для оффлоада нагрузки протокола PCoIP. Здесь же при тестировании да и в целом в проектах мы используем HDX для Citrix и Blast для VMware.
Intel Optane в рамках самого SimpliVity не используется. Отдельных тестов под это не проводили, да и большого смысла под VDI в этом не видим.
Заказчики которые выбирают гиперконвергенцию для филиалов обычно руководствуются задачей упрощения администрирования на месте и возможностью резервного копирования между филиалами (в случае Simplivity). Им нравится что все из одной консоли, причем эта консоль может быть в центральном офисе. На месте не требуется высококвалифицированный сотрудник и решение закрывает сразу несколько задач. Такую задачу можно закрыть по другому и дешевле, но придется пойти на компромисс. Можно привести в пример поездку на работу. Есть несколько вариантов: Общественный транспорт, своя машина или велосипед. Все варианты решают задачу за разные деньги и с разной скоростью. Нельзя сказать что какой-то вариант не правильный. Гиперконвергенция это один из способов решения. Для некоторых это закрытие всех задач сразу, а кто-то наймет выделенного человека, купит писюк с бесплатным гипервизором и будет бекапить скриптами. Все зависит от уровня развития компании.
Если сравнивать со стоимостью Сервера+СХД+Сеть хранения+бекап то выходит выгоднее. К примеру в случае с Simplivity дедупликация позволяет понизить требования к дисковой подсистеме в плане производительности. Понадобится меньше шпинделей для получения целевых показателей. Но иногда выходит дороже. Тогда мы предлагаем заказчику классическое решение с выделенной СХД стартового уровня или SDS. По опыту можно сказать что разброс цен ± 30%. Были случаи когда гиперконвергенция была чуть дороже но заказчик все равно ее выбирал так как ему нравилась простота. Чаще всего во всех проектах у нас нет ультимативности, мы предлагаем заказчикам несколько вариантов на выбор и описываем плюсы и минусы.