Comments 25
Прикольно все названия, кроме одного написать верно. Название компании VMware пишется так.
Как-то всё слишком сложно. Хочу просто включать галочку vSAN и чтобы оно само начало работать без лишней магии.
Я тоже хотел, но оно так не работает. Когда стал погружаться в эту тему, выяснил, что это нормальная ситуация у мировых вендоров, таких как Nvidia, IBM, Dell, Intel, Broadcom, Lenovo. У всех у них нужно сначала обратиться к вендору, создать тикет и по нему тебе окажут "поддержку". Такова современная реальность.
Включил, прощелкал мастером и просто работает - это к винде (пока ещё, хотя и там свои приколы есть).
А тесты дисковой не гоняли? Были бы интересны iops/latency на 4K random начиная с qd1 и до насыщения.
За статью спасибо, но если бы лицензии VMware с vSAN покупались за деньги, то практически уверен, что статьи бы не состоялось :) Покритикую выбор решения: продуктив на проприетарой SDS без техподдержки вендора мне кажется миной замедленного действия. С учётом стоимости лицензии вполне можно рассматривать альтернативы в виде "железной" СХД и FC 16G или iSCSI 10-25G.
На самом деле у нас есть лицензии на продукты VMware, но из-за того, что они ушли, нам не удалось продлить подписку. По поводу поддержки согласен.
А по поводу критики выбора - она уместна. Но посчитав затраты на отдельное hba хранилище с резервированием, а резервное hba для нас существенно, получилось, что это решение вышло дешевле. Свитчи б/у, если что.
Спасибо за статью.
Но в реалиях 23-го я бы строил на открытом ПО (proxmox, truenas etc). Оба умеют в кластеризацию и оба НЕ имеют, напр., таких проблем:
https://www.vmware.com/security/advisories.html
https://www.cvedetails.com/vulnerability-list/vendor_id-252/Vmware.html
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vmware
https://cve.report/vendor/vmware
https://www.opencve.io/cve?vendor=vmware
https://www.helpnetsecurity.com/2023/10/25/cve-2023-34048/
https://www.securitylab.ru/news/543676.php
P.s. Критические уязвимости в продуктах VMware https://www.kaspersky.ru/blog/critical-vulnerabilities-in-vmware-products/33208/
Особую опасность представляет первая уязвимость, CVE-2022-22972, со степенью опасности 9,8 по шкале CVSS. Ее эксплуатация может позволить злоумышленникам >>получить в системе права администратора без какой-либо аутентификации<<
Ынтерпрайз, к-ый "радует" (
Раз предлагаете - видимо, знаете, как строить? Тогда я бы с интересом посмотрел на статью, как с truenas в реальных условиях снимают ту же или большую производительность по сравнению с VSAN, на схожем железе и при схожих параметрах отказоустойчивости.
Особую опасность представляет первая уязвимость
Особенно для on premise инсталляции в закрытом контуре, да.
Верно, ПОЛНОГО аналога vsan в linux пока нет. Но можно подобрать что-то из https://alternativeto.net/software/vsan/
1 Ceph - PVE умеет практически из коробки.
2 Если win не смущает, то https://alternativeto.net/software/starwind-virtual-san/about/
Статья больше про интеграцию RoCEv2. Ни proxmox, ни truenas не умеют в RoCEv2, насколько мне известно. Поправьте, если я не прав
1 https://www.google.com/search?client=firefox-b-e&q=RoCEv2+debian
2 https://manpages.debian.org/testing/rdma-core/rxe.7.en.html
3 https://wiki.debian.org/RDMA
4 RH, тоже самое можно и под deb https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux/7/html/networking_guide/sec-tranferring_data_using_roce
Не соглашусь. Вот как раз vSAN без поддержки обслуживать ИМХО намного проще, чем большинство классических enterprise СХД. Потому что есть доступ ко всем кишкам по умолчанию, нет лока на диски/прошивки/etc, не требуется специализированное железо для замены (aka контроллеры, BBU, etc.) + есть куча материалов и гайдов в открытом доступе по тому, как его строить, обслуживать и траблшутить.
Я просто оставлю это тут RDG for VMware vSAN ESA over NVIDIA RoCE on VMware vSphere 8.0 Тут и как конфигурировать, и результаты тестов (советую смотреть не на финальные несколько графиков с лучшими сценариями, а на полные результаты)
Там, к сожалению, тесты крайне малопоказательны, разве только как референс для пиковых значений по iops и псп.
А еще там ошибка в настройке VDS. По крайней мере в скриптах ESXi 8.0.2 четко прописана проверка на nic teaming.
А по-моему, вполне себе показательны. Хорошо видно, что преимущество достигается исключительно на чтении (желательно последовательном и большими блоками). На запись разницы нет. На мелко-блочном чтении получается порядка 30%, в лучшем случае. Что приводит к тому, что в реальной жизни и под реальной нагрузкой (смешанные блоки 4-64k, смешанное чтение/запись), преимущество по IOPS будет порядка 5-15%. Много кто тестировал и проверял.
Другой вопрос, что при включении RDMA может сильно уменьшается потребление CPU на обработку ввода/вывода, но оценить это "сильно" в % сложно, потому что зависит от конфигурации хоста, профиля нагрузки, реальной загруженности по IOPS (не пиковой/потенциальной) и т.д.
Скажите пожалуйста - всю эту конфигурацию вы получили от вендора? Или нашли сами? Если сами - то как и на базе чего искали?
Спасибо
Эта конфигурация была получена путем поиска по листу совместимости VMware ESA
Может в курсе - какие свичи поддерживаются ОС NVIDIA Onyx ? Я что-то не нашёл в описании. Является ли эта ОС частью ON (Open Network) проекта?
Спасибо.
Новое железо или тонкости интеграции RoCEv2 в VMware vSAN ESA