Comments 37
Подробное рассмотрение особенностей Stretched Cluster выходит за рамки данной публикации.
ждать новый топик? :)
Молодца! Спасибо за статью!
Уровень проделанной работы впечатляет! Все доходчиво и понятно, спасибо!
На VMUG рассказывали, что теперь нужны большие SATA-DOM на 32GB для инсталляции ESXi при использовании vSAN.
Хосты с большим количеством памяти + vSAN требует пространства для хранения логов.
Иначе посылать в support будет нечего.
Хосты с большим количеством памяти + vSAN требует пространства для хранения логов.
Иначе посылать в support будет нечего.
Да, вы правы. Лично я ставил на ssd 60ГБ на моем тестовом стенде.
В продакшене я бы минимум на 1 хост под vCenter локальный raid-1 сделал, чтобы его на vSAN не размещать. Хотя это жирновато, зато отказоустойчиво.
Вообще, надо серьезно задуматься по поводу оптимального размещения ВМ с vCenter в продакшене. До этого не размышлял об этом…
про загрузочные носители:
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.virtualsan.doc/GUID-B09CE19D-A3F6-408C-AE69-35F65CBE66E1.html
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.virtualsan.doc/GUID-4B738A10-4506-4D70-8339-28D8C8331A15.html
В продакшене я бы минимум на 1 хост под vCenter локальный raid-1 сделал, чтобы его на vSAN не размещать. Хотя это жирновато, зато отказоустойчиво.
Вообще, надо серьезно задуматься по поводу оптимального размещения ВМ с vCenter в продакшене. До этого не размышлял об этом…
про загрузочные носители:
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.virtualsan.doc/GUID-B09CE19D-A3F6-408C-AE69-35F65CBE66E1.html
http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.virtualsan.doc/GUID-4B738A10-4506-4D70-8339-28D8C8331A15.html
Не вижу проблем переноса Трейсов vsan на любой другой том и ставить ESXi на мелкие USB флешки.
Что мы и сделали.
Что мы и сделали.
Аж во рту пересохло. Напомнило институт.
Отличная статья, спасибо! Все разложено по полочкам.
Всё хорошо, только забыли сказать, что лицензии стоят как крыло самолёта. Или даже как целый самолёт, а то и два. И это в 90% случаев отбивает всё желание использовать такую вроде-бы замечательную технологию.
Есть такой вопрос — сделал отдельную политику с Number of disk stripes per object = 4, применил ее на одну VM — но судя vCenter — виртуалка как была так и осталась всего на двух физических дисках HDD (capacity) и двух SSD (cache ).
Попробовал перенести на другой СХД и потом вернуть обратно с новой политикой на vSAN — картина осталась прежней.
Виртуалка мелкая, 24 гига всего.
Попробовал перенести на другой СХД и потом вернуть обратно с новой политикой на vSAN — картина осталась прежней.
Виртуалка мелкая, 24 гига всего.
Имеет ли смысл vSAN (сами дисковые группы) строить поверх аппаратных рейдов?
Вы не сможете это сделать!
В качестве storage-контроллера может использоваться SAS/SATA HBA или RAID-контроллер, они должны функционировать в режиме passthrough (диски отдаются контроллером как есть, без создания raid-массива) или raid-0.
В качестве storage-контроллера может использоваться SAS/SATA HBA или RAID-контроллер, они должны функционировать в режиме passthrough (диски отдаются контроллером как есть, без создания raid-массива) или raid-0.
У нас есть тестовые конфигурации (успешно работают на LSI-9261) на RAID-1, RAID-0, RAID-10 и без рейдов вовсе.
Стоит лишь вопрос целесообразности и эффективности, какова позиция разработчиков на этот счет? Я что-то не нагуглил ортодоксального пути.
Стоит лишь вопрос целесообразности и эффективности, какова позиция разработчиков на этот счет? Я что-то не нагуглил ортодоксального пути.
Интересно очень! А как выглядят эти ваши тестовые конфигурации?
Тестовые конфигурации выглядят убого, и все разные. Цель этих тестовых серверов — попробовать функционал, поэтому под капотом разное железо и разные диски от зеленых WD до HGST в разных количествах. Поэтому о бенчмарках даже о синтетических и речи не идет, да и некогда и некому этим заниматься.
Я про другое спрашивал. Как вы рэйды сконфигурировали? Вот есть дисковая группа на серваке: 1 ssd под кэш, и несколько дисков под капасити. Допустим 8 дисков под каписити у нас есть на серваке. Можно их как врекомендациях отдать в дисковою группу без аппаратного рэйда. Можно все 8 аппаратно объединить в raid-10, тогда теоретически вСАН удидит один большой капасити диск в этой группе. Кстати, если уж так извращаться, то можно и про рэйд 5 или 6 подумать. Можно сделать 4 рэйд-1 по 2 диска, тогда вСАН увидит 4 капасити диска в группе. А вы как делали?
под капотом разное железо и разные диски — это как? на одном хосте 4 диска 5400 по 2ТБ, на другом 8 дисков 7200 по 6ТБ, и так далее?
5400 конечно нет, но грубо говоря в остальном — именно так :)
это неправильно, если вы хотите добиться оптимальной производительности, надежности, отказоустойчивости и поддержки, то нужно делать как в рекомендациях Вари. Аппаратная конфигурация хостов в идеале должна быть идентична.
Увы, с точки зрения бюджета мы не все можем себе позволить, приходится чем-то жертвовать. А про идентичность конфигурации — это ваша рекомендация или разработчиков? Потому что мне не ясно, откуда такая рекомендация, если это SDS.
Так ВМваря вообще решение для очень богатых контор сама по себе. vSAN тоже штука дорогая. Это не тот случай когда реше6ие позволяет сделать из говна конфетку. Софт дорогой, поддержка его тоже. Железо тоже требуется рекомендованное и совместимое. Хорошее новое железо. В идеале все железо должно быть идентично на хостах. Это рекомендация производителя. Делать кластер из хостов с разными дисками, их количеством, с отличающимися контроллерами и другим железом не рекомендуется. Оно будет работать не оптимально.
Вы цены на лицензии вари и Висан видели? Неразумно столько денег платить за варю и разворачивать ее на говножелезе. Или вы старые пираты и не знаете слов лицензионного соглашения?
Пардон за резкие фразы если что…
Вы цены на лицензии вари и Висан видели? Неразумно столько денег платить за варю и разворачивать ее на говножелезе. Или вы старые пираты и не знаете слов лицензионного соглашения?
Пардон за резкие фразы если что…
Вы думаете что SDS позволяет сделать на любом разношерстном железе реактивный истребитель? У любого sds есть свои требования и рекомендации. На чем соберёте, так и полетит, если заведётся.
Ну даже истребители бывают разные. На медленном железе должен получиться медленный кластер. Но он должен получиться, иначе это плохое SDS.
Само по себе SDS должно лишь давать гибкость и небольшой программный оверхед, быстродействие то тут причем.
Само по себе SDS должно лишь давать гибкость и небольшой программный оверхед, быстродействие то тут причем.
У вас получится, работать будет, можете собрать кластер из разных хостов, с разными дисками и их количеством. Просто хосты где диски медленнее или их меньше будут тормозить остальные хосты. Тоже самое с полезным пространством. Можно даже в кластер втыкать хосты без дисков.
Про принцип самого медленного верблюда в караване я в курсе, я как раз это упоминал в обсуждении с коллегами в качестве аргумента, зачем в принципе нужно одинаковое железо.
Другой разговор, что мы не обладаем цифрами. Что если разница между самым быстрым верблюдом и самым медленным в производительности будет в 0.01%?
Другой разговор, что мы не обладаем цифрами. Что если разница между самым быстрым верблюдом и самым медленным в производительности будет в 0.01%?
целесообразность и эффективность использовать аппаратный raid с избыточностью — прямо скажем сомнительные. vSAN реализует отказоустойчивость и производительность хранилища программно и хочет работать с железом напрямую, интеллект контроллера тут будет только мешать.
raid-1 или 10 — у вас полезная ёмкость ещё в 2 раза меньше будет
а производительность вы мерили? сравнивали с результатом без рэйда?
raid-1 или 10 — у вас полезная ёмкость ещё в 2 раза меньше будет
а производительность вы мерили? сравнивали с результатом без рэйда?
В коллективе мнения расходятся, есть версия, что аппаратный рейд будет давать небольшой прирост производительности (если отключить кеши), но с потерей гибкости.
Как я писал выше, производительность замерить не можем с той точностью, которая бы дала однозначный ответ. В Ceph используются похожие механизмы из-за схожей архитектуры системы, и разработчики Ceph четко заявляют, что строить кластер хранения поверх RAID — бессмысленно, и в большинстве случаев дает лишний оверхед с потерей гибкости. В случае с VMWare никто четко не говорит, что это хорошо или плохо, просто говорят, что допускается, без подробностей.
Вы задаете мне вопросы по производительности, ответы на которые если бы у меня были, я бы сюда не вопрошал))
Как я писал выше, производительность замерить не можем с той точностью, которая бы дала однозначный ответ. В Ceph используются похожие механизмы из-за схожей архитектуры системы, и разработчики Ceph четко заявляют, что строить кластер хранения поверх RAID — бессмысленно, и в большинстве случаев дает лишний оверхед с потерей гибкости. В случае с VMWare никто четко не говорит, что это хорошо или плохо, просто говорят, что допускается, без подробностей.
Вы задаете мне вопросы по производительности, ответы на которые если бы у меня были, я бы сюда не вопрошал))
Интересно, где и кто говорит, что это допускается? Можете ссылку прислать? Я погуглил, не нашел. Я был уверен, что vSAN не заработает на контроллерах в режиме отличном от passthrough или raid-0. Даже мысли пробовать поднимать аппаратный рэйд не было. И смысла в этом не вижу.
Вам поддержка от производителя не нужна?
Вам поддержка от производителя не нужна?
Возможно я не правильно понял письмена Ctrl+F «RAID 1 over RAID 1». Но теперь я даже не могу найти, где в Ceph писали про избыточность рейдов.
Так получилось, что у нас собрали тестовый кластер на том, что было, а было: несколько старых серверов с уже собранными разными рейдами. У меня тоже не возникало мысли поднимать vSAN на зеркалах, но вот у коллеги как-то оно так само получилось, и у нас всплыл вопрос. В дальнейшем мы будем пробовать на голых дисках.
А о поддержке рано думать.
Так получилось, что у нас собрали тестовый кластер на том, что было, а было: несколько старых серверов с уже собранными разными рейдами. У меня тоже не возникало мысли поднимать vSAN на зеркалах, но вот у коллеги как-то оно так само получилось, и у нас всплыл вопрос. В дальнейшем мы будем пробовать на голых дисках.
А о поддержке рано думать.
Ортодоксальный путь — следовать рекомендациям Вари, я их написал выше. Если по-другому, то в случае проблем вы лишаетесь поддержки
Sign up to leave a comment.
Теоретические основы VMware Virtual SAN 6.5