Size: a a a

2019 November 29

N

Nikolay Kulikov in VMware vSAN
Изначально, рекомендации по увеличению RF на больших кластерах в распределенных системах связано с тем, что чем больше кластер, тем больше вероятность двойного одновременного сбоя в этом кластере. При этом, если весь кластер может держать только один сбой, то у нас растет домен отказа и вероятность сбоя всех ВМ в кластере
источник

N

Nikolay Kulikov in VMware vSAN
Но у vSAN такой зависимости нет, потому что нам не важно число отказов в кластере - у нас нет распредленной ФС или общей метадата
источник

N

Nikolay Kulikov in VMware vSAN
Нас единственное волнует, чтобы не потерять обе копии данных на кластере. Поэтому если кластер большой и с FTT=1, то при двойном сбое у нас могут постарадать только часть ВМ, а остальные продолжат работать.
источник

N

Nikolay Kulikov in VMware vSAN
Более того, размер кластера никак не вляет на количество объектов, потому что их кол-во зависит исключительно от  ВМ/vmdk + Storage Policy
источник

FK

Felix Kudryavtsev in VMware vSAN
Сбой-то может быть и один, но чаще всего приходится обслуживать систему, обновления какие-нибудь накатывать, например. Если во время обслуживания произойдет сбой, то есть вероятность потери данных, так как редко кто выводит хост в обслуживание с полной эвакуацией данных. А больше хостов, дольше обслуживание.
источник

N

Nikolay Kulikov in VMware vSAN
Я про другое
источник

N

Nikolay Kulikov in VMware vSAN
если у вас 64 хоста, то у вас 64 хоста
источник

N

Nikolay Kulikov in VMware vSAN
А в каком количестве кластеров - это дело другое. И на FTT влияние это не оказывает
источник

AK

Alexander Kupchinetsky in VMware vSAN
Еще это могло быть сравнение ftt2/EC c ftt1/mirroring
Оверхед 150% против 200%, держим 2 сбоя, а не 1, перформанс по чтению растёт
Перформанс по записи - в реальной жизни, а не в синтетике разница может быть и незаметна
Но надо от 6 хостов...
источник

N

Nikolay Kulikov in VMware vSAN
Но с утверждением, что "надежнее использовать FTT=2 вместо FTT=1." спорить трудно. И это действительно так. И какую SP выбирать - зависит от рисков и требований к ВМ. Поэтому да, на AF большинство заказчиков меняет Default SP на EC FTT=2, а потом назначает отдельные при необходимости. Но для гибридов, как показывает практика, все спокойно живут на стандартной с FTT=1 Mirroring
источник

N

Nikolay Kulikov in VMware vSAN
Я бы сказал даже больше - у вас 3 хоста, то двойной одновременный гарантированно уложит всё. Если у вас 60 хостов, то двойной одновременный сбой может уложить только часть, да и то с меньшей вероятностью.
источник

N

Nikolay Kulikov in VMware vSAN
И в этом, кстати, большой плюс vSAN по сравнению с остальными -  у больших кластеров на vSAN доступность заметно выше из-за отсутствия единых распределенных ФС/метаданных.
источник

DM

Dmitriy Mihaylenko in VMware vSAN
Dmitriy Mihaylenko
Я попробую ночью перегрузить vcenter, по результату отпишу
Ребут vcsa помог, все VM стали complince
источник
2019 November 30

T

The in VMware vSAN
vSAN - это и есть ФС во всех отношениях. Все попытки это отрицать ведут в книги по CS :)
источник

T

The in VMware vSAN
Alexander Kupchinetsky
Еще это могло быть сравнение ftt2/EC c ftt1/mirroring
Оверхед 150% против 200%, держим 2 сбоя, а не 1, перформанс по чтению растёт
Перформанс по записи - в реальной жизни, а не в синтетике разница может быть и незаметна
Но надо от 6 хостов...
В реальной жизни в vSAN аналог RAID6 несёт в себе все штрафы дискового аналога. Другое дело, что если это соответствует требованиям и учитывалось при сайзинге - то нет проблем.
источник

T

The in VMware vSAN
Для "толстой" ВМ в многотерабайт/многодисков плюс страйпинг шанс отказа всё же растёт. И тогда FTT=2 может повысить надёжность; для критикал сервиса, например. Но если у вас ВМ по итогу размазалась по всему кластеру - что-то пошло не так ещё на этапе подбора для capacity tier.
источник

N

Nikolay Kulikov in VMware vSAN
The
vSAN - это и есть ФС во всех отношениях. Все попытки это отрицать ведут в книги по CS :)
источник

T

The in VMware vSAN
ЧТД 👍
источник

N

Nikolay Kulikov in VMware vSAN
HOL-2013-01-SDC - Project Pacific - Lightning Lab
источник

N

Nikolay Kulikov in VMware vSAN
HOL-2032-01-CNA - Tech Preview: VMware Tanzu Mission Control
источник