EMC ScaleIO против виртуальной сети Starwind
Я создаю тестовую лабораторию, чтобы оценить лучшее решение для будущего производственного использования. Производственная ферма предназначена для малого и среднего бизнеса, поэтому бюджет присутствует, но он также ограничен.
Цель производства: 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, напротив, распределяет данные по узлам и позволяет добавлять новые хранилища и перебалансировать тома.
Итак, мои вопросы:
- Верны ли мои предположения, или Starwind VSAN позволяет создать том HA на нескольких дисках в каждом узле и добавлять диски позже?
- Какое решение лучше для моего приложения, по вашему мнению (пожалуйста, объясните)?
- Каковы недостатки рекомендованного решения?
Заранее спасибо!
2 ответа
Здесь нет ничего хорошего или плохого: оба решения ref'd просто очень отличаются по способу их масштабирования, как они распределяют данные по узлам кластера и как они обрабатывают сбои компонентов.
1) Широкое чередование с данными. SIO выполняет то, что называется "широким чередованием": они хранят объемные данные на всех узлах кластера (так же, как это делают VMware VSAN и HPE VSA) более или менее одинаково, в то время как StarWind заботится о том, что называется "локальностью данных" (так же, как Nutanix NDFS и SimpliVity/HPE делают) и хранит данные об ограниченном количестве "партнеров". На самом деле есть плюсы и минусы для обоих подходов.
https://www.nutanix.com/2013/12/03/data-locality-sql-vdi-on-the-same-nutanix-cluster/
https://www.simplivity.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.simplivity.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: В общем, я бы предложил создать POC для обоих кандидатов в шорт-лист и посмотреть, насколько хорошо все идет.
Краткий ответ: оба решения будут соответствовать вашим требованиям.
Как уже упоминалось предыдущим постером, они просто работают по-другому.
Если вы хотите узнать о преимуществах / недостатках каждого решения, просто свяжитесь с обоими поставщиками и спросите их техников перед продажей, что вы хотели бы знать. После этого разверните PoC и перепроверьте, что они вам сказали.