В связи со сменой Hostkey основного ЦОД со Стордаты на Мегафон и переноса основной площадки вирутуализации и перехода на Server 2012 для Windows нам пришлось делать новый высокопроизводительный файлер для выдачи iSCSI/NFS/SMB таргетов на кластеры и нашим клиентам для организации частных облаков/кластеров. Мы выбрали и внедрили NexentaStor и вот что из этого вышло и как мы это делали
В прошлую пятницу мы рассказывали об опыте с развертыванием 180 ВПС посредством SolusVM, который нам всем понравился за исключением отсутствия тонкого выделения ресурсов. Именно это было нам важно для обеспечения беспрерывного обслуживания кластера на базе KVM с Linux, так и на Hyper-V Windows Server 2012.
Последние 2 года мы работали с переменным успехом на Старвинде. Переменный успех заключался в том, что о высокодоступном кластере из двух равнозначных файлеров для Hyper-V (как планировалось) пришлось забыть — раз в неделю он разваливался. В итоге более-менее надежно стало работать только с основным и резервным, куда проводилась асинхронная репликация. С помощью настроек MPIO мы отвадили кластер Hyper-V использовать резервный файлер во всех случаях кроме аварий, но иногда таргеты сами сползали на архивный файлер.
Еще минус — с уже созданным томом нельзя НИЧЕГО делать: ни мигрировать, не расширять, не менять настройки и т.п. Если том имеет размер около 8Тб и под постоянной нагрузкой от 1000 до 2000 IOPS — это проблема, а каждая миграция ночной кошмар админа с месячной подготовкой и подменными серверами. Всякие мелочи типа ресинхронизации которая занимает около 3 дней, синих экранов смерти, нестабильной дедупликации и т.п. оставим за скобками. Попытки докопаться до сути проблемы через поддержку — дохлый номер, пришлите логи и тишина или невнятный ответ не отражающий сути явления. Любой апгрейд версии == перезагрузка таргета == пересинхронизация на 2-3 дня == ночной кошмар.
Система работает на Windows Server 2008 Standard edition. 2 машины по 2 процессора, ~2000 рублей в месяц по SPLA на каждую. 48000 рублей в год. поддержка нашей HA лицензии на 8Тб еще около 60000р. Итого, базовый самый TCO около 100000р в год.
Мы долго искали альтернативу и начали присматриваться к системе NexentaStor на базе ZFS/Open Solaris (да я знаю что там не совсем опен солярис, речь не про это). У Нексенты нашелся грамотный небольшой местный партнер, который помог нам все настроить, подсказал нужную конфигурацию и все настроил как положено. На все от начала тестов до запуска ушло около месяца.
Я не буду касаться теории ZFS, про это написана масса постов.
Сразу хочу сказать – HCL (Hardware compatibility list) наше все. Даже не пытайтесь ставить туда что-то не описанное в нем, счастья не будет. Как хостеру с парком в 1000 своих машин, нам было относительно просто – залез в шкаф с запчастями или свободный сервер и достал альтернативную деталь. Корпоративному клиенту будет непросто в случае ошибки. Солярис не имеет такой массы драйверов как другие популярные ОС.
Лицензия на 8Тб и поддержкой нам обошлась в 1700 долларов, есть бесплатная версия без поддержки на 18Тб. Все то же самое, но без полезных и нужных плагинов. TCO – только контракт на поддержку, около 30000р в год. Экономим на пустом месте 70000р.
Результатом нашей совместной работы стал сервер следующей конфигурации:
Специальный файлер Supermicro, SuperChassis 847E16.
4U, резервированный блок питания, 36 3,5” дисков горячей замены с обеих сторон, 2 качественных бэкплейна, крупные вентиляторы с возможностью замены и место под стандартную мать с 8 низкопрофильными платами расширения.
Материнская плата Supermicro, 2x s1366, 6xPCIe 8x, 2xSAS 2.0, процессоры 2x Xeon E5520, 192Gb DDR3 LV RAM.
3 контроллера LSI HBA LSI9211-8i – Нексенте нужны сами диски, без RAID
1 контроллер LSI HBA LSI9200-8e – для расширения дисковыми полками по SAS.
1 контроллер Adapteс на 4 порта для подключения SSD
1 сетевой адаптер 10G Intel 520 на 2 порта SFP+, через медные модули прямого подключения через него работаем с коммутатором
Диски – 35xHitachi Ultrastar SAS 300Gb 15K
Один порт занят хотсвопной коробкой AgeStar с двумя небольшими 2,5” SSD дисками для хранения логов ZFS (ZIL), расходный материал, надо легко и просто менять (а коробка как раз входит в 3,5” слот корпуса как родная). Коробка подключена к Адаптеку.
Один SSD на 300Gb серверного класса Intel 710, это центральный кэш ZFS. Бытовые не годятся, выгорают на раз. Подключен к Адаптеку.
Нексента имеет кэш в оперативной памяти и держит в памяти таблицу дедупликации и метаданные. Чем больше памяти тем лучше. Мы поставили по максимуму, 12х16Gb=192.
Бюджет мероприятия: ~350 000р.
Мы имеем на материнской плате 2 гигабитных порта и 2 10G порта на контроллере Intel 520. 10G порты подключены в коммутатор Cisco 2960S – 24 порта 1G и 2 порта 10G, SFP+ (~90000р). Соединены они через медные SFP+ direct connect, это недорого — около 1000р за метровый шнур с разъемами SFP+.
В ближайшее время к нам приедет коммутатор Extreme Summit 640 на 48 портов 10G SFP+ (~350000р), тогда туда мы файлер и переткнем, а Циску будем использовать для снижения на 1Г.
Как оказалось, самый надежный способ это аналог RAID50, собираются тройки дисков в RAIDZ1 и все вместе добавляются в общий дисковый пул. К ним добавляется некоторое количество дисков для горячей замены. Как известно, в ZFS есть специальный метод scrub read, который сверяет в свободное время реальное содержимое диска с контрольными суммами блоков и если находит разницу, то сразу это исправляет. Если ошибок много – диск выходит из массива, на его место ставится резервный.
Обычная работа через интуитивно понятный веб-интерфейс. Есть консоль с простым синтаксисом и обычными командами управления ZFS. В вебе статистика, генерация таргетов iSCSI/NSF/SMB, создание точек монтирования и управление ими. Тут как раз самое главное зачем мы взяли Нексенту — thin provisioning & deduplication. Для нас в мире виртуализации дедупликация это все – в каждой из сотен виндовых ВПС 10Гб места почти одинаковые. В нексенте они собираются вместе на уровне блоков.
Далее, клиенты заказывают крупные диски для вируталок и не используют их полностью. Среднее использование вместе с ОС у нас порядка 15Г. В Нексенте мы можем сделать виртуальный iSCSI таргет (расшареную точку монтирования по ISCSI) с произвольным размером, например 500Т. На использование дисков это не влияет, как там появляются новые данные – место расходуется.
Емкость пула можно расширить в любой момент добавлением новых дисков. Это не драматическое событие при расширении RAID6 емкостью 10Tb на традиционном контроллере, вы просто добавляете еще дисков и система начинает их использовать. Ничего не перестраивается, данные никуда не перемещаются.
Нексента дает полную статистику как она себе чувствует и работает – тут и данные по нагрузке на процессор, сетевые интерфейсы, память, кэш, разбивка по дискам, IOPS по дискам/таргетам и т.п.
Натура ZFS – простота снэпшотов. Система умеет делать снимки с точек монтирования с заданным интервалом и складывать их на внешнее хранилище. Можно сделать асинхронную репликацию на нексенту рядом. Сами вирутальные машины можно бакапить средствами используемой системы вирутализации.
Да, 10Г и multi-tiered storage творят почти чудеса. Мы получили на тестах со стенда Windows 2008 Standard edition с штатным инициатором iSCSI и карточкой Qlogic задержку порядка 2-4 ms, линейные трансферы порядка 700-800 Мбайт в секунду и больше 31000 IOPS на чтение при глубине очереди в 16 запросов. На запись IOPS было около 25000, но в нашей среде массовой виртуализации чтение к записи относится примерно 1 к 10. В одну линию мы имеем порядка 3000 IOPS. Размер файла для тестов на скорость не влияет, можно его хоть 1Т сделать.
По мере заполнения дисков и роста нагрузки мы будем добавлять еще диски, что добавит скорости и места.
Основное предназначение этого решения отдавать iSCSI таргеты в высокодоступный кластер Windows Server 2012 для работы Cluster Shared Volumes и в ноды KVM, работающие под SolusVM для организации LVM с которых и идет работа. Дедупликация и все вышеописанные плюшки позволяют нам держать цены на отличном уровне.
Второе предназначение – предоставить клиентам услугу iSCSI таргет как услуга с оплатой по факту использования, что бы нашим клиентам больше не надо было делать свой файлер, если нужен кластер. Так как мы специализируемся по крупным выделенным серверам с SLA 4 часа, то мы знаем для чего их берут. Можно будет серьезно экономить за счет использования централизованной инфраструктуры.
Мы теперь можем раздавать таргеты на скорости 1Гб, и 10Гб. Клиентские таргеты автоматически снапшотятся и реплицируются на архивное хранилище.
Надеюсь, этот пост окажется полезным и позволит избежать граблей при выборе решения для многоуровневых бюджетных хранилищ. Будем работать, буду писать наблюдения. Ждем комментариев и добро пожаловать в HOSTKEY.
В прошлую пятницу мы рассказывали об опыте с развертыванием 180 ВПС посредством SolusVM, который нам всем понравился за исключением отсутствия тонкого выделения ресурсов. Именно это было нам важно для обеспечения беспрерывного обслуживания кластера на базе KVM с Linux, так и на Hyper-V Windows Server 2012.
Последние 2 года мы работали с переменным успехом на Старвинде. Переменный успех заключался в том, что о высокодоступном кластере из двух равнозначных файлеров для Hyper-V (как планировалось) пришлось забыть — раз в неделю он разваливался. В итоге более-менее надежно стало работать только с основным и резервным, куда проводилась асинхронная репликация. С помощью настроек MPIO мы отвадили кластер Hyper-V использовать резервный файлер во всех случаях кроме аварий, но иногда таргеты сами сползали на архивный файлер.
Еще минус — с уже созданным томом нельзя НИЧЕГО делать: ни мигрировать, не расширять, не менять настройки и т.п. Если том имеет размер около 8Тб и под постоянной нагрузкой от 1000 до 2000 IOPS — это проблема, а каждая миграция ночной кошмар админа с месячной подготовкой и подменными серверами. Всякие мелочи типа ресинхронизации которая занимает около 3 дней, синих экранов смерти, нестабильной дедупликации и т.п. оставим за скобками. Попытки докопаться до сути проблемы через поддержку — дохлый номер, пришлите логи и тишина или невнятный ответ не отражающий сути явления. Любой апгрейд версии == перезагрузка таргета == пересинхронизация на 2-3 дня == ночной кошмар.
Система работает на Windows Server 2008 Standard edition. 2 машины по 2 процессора, ~2000 рублей в месяц по SPLA на каждую. 48000 рублей в год. поддержка нашей HA лицензии на 8Тб еще около 60000р. Итого, базовый самый TCO около 100000р в год.
Нексента
Мы долго искали альтернативу и начали присматриваться к системе NexentaStor на базе ZFS/Open Solaris (да я знаю что там не совсем опен солярис, речь не про это). У Нексенты нашелся грамотный небольшой местный партнер, который помог нам все настроить, подсказал нужную конфигурацию и все настроил как положено. На все от начала тестов до запуска ушло около месяца.
Я не буду касаться теории ZFS, про это написана масса постов.
Сразу хочу сказать – HCL (Hardware compatibility list) наше все. Даже не пытайтесь ставить туда что-то не описанное в нем, счастья не будет. Как хостеру с парком в 1000 своих машин, нам было относительно просто – залез в шкаф с запчастями или свободный сервер и достал альтернативную деталь. Корпоративному клиенту будет непросто в случае ошибки. Солярис не имеет такой массы драйверов как другие популярные ОС.
Лицензия на 8Тб и поддержкой нам обошлась в 1700 долларов, есть бесплатная версия без поддержки на 18Тб. Все то же самое, но без полезных и нужных плагинов. TCO – только контракт на поддержку, около 30000р в год. Экономим на пустом месте 70000р.
Результатом нашей совместной работы стал сервер следующей конфигурации:
Матчасть
Специальный файлер Supermicro, SuperChassis 847E16.
4U, резервированный блок питания, 36 3,5” дисков горячей замены с обеих сторон, 2 качественных бэкплейна, крупные вентиляторы с возможностью замены и место под стандартную мать с 8 низкопрофильными платами расширения.
Материнская плата Supermicro, 2x s1366, 6xPCIe 8x, 2xSAS 2.0, процессоры 2x Xeon E5520, 192Gb DDR3 LV RAM.
3 контроллера LSI HBA LSI9211-8i – Нексенте нужны сами диски, без RAID
1 контроллер LSI HBA LSI9200-8e – для расширения дисковыми полками по SAS.
1 контроллер Adapteс на 4 порта для подключения SSD
1 сетевой адаптер 10G Intel 520 на 2 порта SFP+, через медные модули прямого подключения через него работаем с коммутатором
Диски – 35xHitachi Ultrastar SAS 300Gb 15K
Один порт занят хотсвопной коробкой AgeStar с двумя небольшими 2,5” SSD дисками для хранения логов ZFS (ZIL), расходный материал, надо легко и просто менять (а коробка как раз входит в 3,5” слот корпуса как родная). Коробка подключена к Адаптеку.
Один SSD на 300Gb серверного класса Intel 710, это центральный кэш ZFS. Бытовые не годятся, выгорают на раз. Подключен к Адаптеку.
Нексента имеет кэш в оперативной памяти и держит в памяти таблицу дедупликации и метаданные. Чем больше памяти тем лучше. Мы поставили по максимуму, 12х16Gb=192.
Бюджет мероприятия: ~350 000р.
Сетевое окружение
Мы имеем на материнской плате 2 гигабитных порта и 2 10G порта на контроллере Intel 520. 10G порты подключены в коммутатор Cisco 2960S – 24 порта 1G и 2 порта 10G, SFP+ (~90000р). Соединены они через медные SFP+ direct connect, это недорого — около 1000р за метровый шнур с разъемами SFP+.
В ближайшее время к нам приедет коммутатор Extreme Summit 640 на 48 портов 10G SFP+ (~350000р), тогда туда мы файлер и переткнем, а Циску будем использовать для снижения на 1Г.
Особенности разбивки дисков
Как оказалось, самый надежный способ это аналог RAID50, собираются тройки дисков в RAIDZ1 и все вместе добавляются в общий дисковый пул. К ним добавляется некоторое количество дисков для горячей замены. Как известно, в ZFS есть специальный метод scrub read, который сверяет в свободное время реальное содержимое диска с контрольными суммами блоков и если находит разницу, то сразу это исправляет. Если ошибок много – диск выходит из массива, на его место ставится резервный.
Управление
Обычная работа через интуитивно понятный веб-интерфейс. Есть консоль с простым синтаксисом и обычными командами управления ZFS. В вебе статистика, генерация таргетов iSCSI/NSF/SMB, создание точек монтирования и управление ими. Тут как раз самое главное зачем мы взяли Нексенту — thin provisioning & deduplication. Для нас в мире виртуализации дедупликация это все – в каждой из сотен виндовых ВПС 10Гб места почти одинаковые. В нексенте они собираются вместе на уровне блоков.
Далее, клиенты заказывают крупные диски для вируталок и не используют их полностью. Среднее использование вместе с ОС у нас порядка 15Г. В Нексенте мы можем сделать виртуальный iSCSI таргет (расшареную точку монтирования по ISCSI) с произвольным размером, например 500Т. На использование дисков это не влияет, как там появляются новые данные – место расходуется.
Емкость пула можно расширить в любой момент добавлением новых дисков. Это не драматическое событие при расширении RAID6 емкостью 10Tb на традиционном контроллере, вы просто добавляете еще дисков и система начинает их использовать. Ничего не перестраивается, данные никуда не перемещаются.
Нексента дает полную статистику как она себе чувствует и работает – тут и данные по нагрузке на процессор, сетевые интерфейсы, память, кэш, разбивка по дискам, IOPS по дискам/таргетам и т.п.
Резервное копирование
Натура ZFS – простота снэпшотов. Система умеет делать снимки с точек монтирования с заданным интервалом и складывать их на внешнее хранилище. Можно сделать асинхронную репликацию на нексенту рядом. Сами вирутальные машины можно бакапить средствами используемой системы вирутализации.
Производительность
Да, 10Г и multi-tiered storage творят почти чудеса. Мы получили на тестах со стенда Windows 2008 Standard edition с штатным инициатором iSCSI и карточкой Qlogic задержку порядка 2-4 ms, линейные трансферы порядка 700-800 Мбайт в секунду и больше 31000 IOPS на чтение при глубине очереди в 16 запросов. На запись IOPS было около 25000, но в нашей среде массовой виртуализации чтение к записи относится примерно 1 к 10. В одну линию мы имеем порядка 3000 IOPS. Размер файла для тестов на скорость не влияет, можно его хоть 1Т сделать.
По мере заполнения дисков и роста нагрузки мы будем добавлять еще диски, что добавит скорости и места.
Использование
Основное предназначение этого решения отдавать iSCSI таргеты в высокодоступный кластер Windows Server 2012 для работы Cluster Shared Volumes и в ноды KVM, работающие под SolusVM для организации LVM с которых и идет работа. Дедупликация и все вышеописанные плюшки позволяют нам держать цены на отличном уровне.
Второе предназначение – предоставить клиентам услугу iSCSI таргет как услуга с оплатой по факту использования, что бы нашим клиентам больше не надо было делать свой файлер, если нужен кластер. Так как мы специализируемся по крупным выделенным серверам с SLA 4 часа, то мы знаем для чего их берут. Можно будет серьезно экономить за счет использования централизованной инфраструктуры.
Мы теперь можем раздавать таргеты на скорости 1Гб, и 10Гб. Клиентские таргеты автоматически снапшотятся и реплицируются на архивное хранилище.
Надеюсь, этот пост окажется полезным и позволит избежать граблей при выборе решения для многоуровневых бюджетных хранилищ. Будем работать, буду писать наблюдения. Ждем комментариев и добро пожаловать в HOSTKEY.
