Я создаю испытательную лабораторию, чтобы оценить лучшее решение для будущего использования в производстве. Производственная ферма предназначена для малого и среднего бизнеса, поэтому бюджет есть, но он также ограничен.
Цель для производства: 3 гиперконвергентных сервера с отказоустойчивым кластером виртуализации Windows Server 2012 R2 и программно-определяемым хранилищем в качестве общего хранилища. В ближайшее время кластер будет расширен до 5 серверов. Сеть SAN выделена.
Цель для тестовой лаборатории: найти решение SDS, отвечающее следующим критериям:
1. Предоставляет общее хранилище для кластера Hyper-V.
2. Масштабирование: можно добавлять и удалять диски (а также, желательно, узлы) без выключения кластера.
3. Отказоустойчивый. Доступно после потери 1 узла (если можно восстановить после потери 2 узлов - отлично!).
4. Низкая нагрузка на сеть / время задержки (также будет использоваться для SQL Server).
5. Иметь разумную цену (по этой причине использование Storage Spaces Direct неприемлемо).
После прочтения и просмотра некоторых продуктов мой короткий список - EMC ScaleIO и Starwind Virtual SAN.
Я попробовал их оба и обнаружил, что Starwind VSAN обеспечивает довольно ограниченную HA: как я это понял, это решение только зеркалирует виртуальный диск (а именно файл) на узлах и позволяет увеличивать емкость только в пределах диска, на котором он находится. ScaleIO, напротив, распределяет данные по узлам и позволяет добавлять новое хранилище и ребалансировка тома.
Итак, мои вопросы:
Заранее спасибо!
В этом нет ничего хорошего или плохого: оба реферируемых решения сильно различаются по способу масштабирования, распределению данных между узлами кластера и обработке отказов компонентов.
1) Широкое чередование или расположение данных. SIO выполняет так называемое «широкое чередование»: они хранят объемные данные на всех узлах кластера (так же, как это делают VMware VSAN и HPE VSA) более или менее одинаково, в то время как StarWind заботится о том, что называется «локальностью данных» (так же, как Nutanix NDFS и SimpliVity / HPE do) и хранит данные об ограниченном количестве «партнеров». На самом деле у обоих подходов есть свои плюсы и минусы.
https://www.nutanix.com/2013/12/03/data-locality-sql-vdi-on-the-same-nutanix-cluster/
https://www.simpliversity.com/blog/2016/05/importance-data-locality/
https://www.starwindsoftware.com/data-locality-page
2) Единое унифицированное адресное пространство против виртуальных дисков. SIO действительно может создать единое унифицированное адресное пространство, но на самом деле это бесполезная (по крайней мере, в лучшем случае плохая идея!) Функция в вашей среде: Microsoft / Hyper-V действительно требует ПО МЕНЬШЕ одного CSV / виртуального LUN на узел кластера, поэтому В вашем случае оптимальное количество виртуальных LUN одинаково и не имеет значения, используете ли вы SIO или StarWind.
https://technet.microsoft.com/en-us/library/jj612868%28v=ws.11%29.aspx
https://www.petri.com/how-many-csvs-should-a-scale-out-file-server-have
https://blogs.msdn.microsoft.com/clustering/2013/12/02/cluster-shared-volume-csv-inside-out/
3) Количество узлов и отказоустойчивость. SIO здесь очень похож на Ceph: ему требуется довольно много узлов (8-10) для получения приемлемой производительности (благодаря «широкому чередованию»). Также убедитесь, что вы понимаете, что SIO - это только репликация, а конечная емкость равна (N-1) / 2, поэтому пять узлов дадут вам емкость 2 узла, которую можно использовать с двухсторонней репликацией, и возможность потерять только один узел (N + 1). StarWind использует комбинацию кодов репликации и локального восстановления (кодирование стирания), чтобы выдерживать несколько сбоев одновременно благодаря нескольким доменам сбоя, есть не только защита репликации между узлами, но и локальная защита типа RAID, такая же способ SimpliVity и аналогичный тому, что Microsoft делает в Azure / S2D.
https://www.emc.com/collateral/white-papers/h15148-emc-scaleio-deployment-guide.pdf
https://www.simpliversity.com/blog/2016/10/data-storage-built-resiliency/
https://www.microsoft.com/en-us/research/publication/erasure-coding-in-windows-azure-storage/
https://www.starwindsoftware.com/grid-architecture-page
TL; DR: В общем, я бы предложил построить P.O.C. для обоих кандидатов в шорт-лист и посмотрите, как все пойдет.
Короткий ответ: оба решения будут соответствовать вашим требованиям.
Как уже упоминалось в предыдущем постере, просто они работают по-другому.
Если вы хотите узнать о преимуществах / недостатках каждого решения, просто свяжитесь с обоими поставщиками и спросите у их специалистов по предпродажной подготовке все, что вам нужно. После этого разверните PoC и перепроверьте, что вам сказали.