ЕО
> они вообще не выходят из строя
mmmmmm
mmmmmm
> они вообще не выходят из строя
mmmmmm
Size: a a a
2020 February 12
DZ
хахахахахах
N
PR
Замените слово "кассандра" на "gcp persistent disk", а "кортекс" на "викторияметрикс". Получите справедливое утверждение про вм, при том, что gcp диски намного проще в настройке и сопровождении по сравнению с кассандрой, и они вообще не выходят из строя, в отличие от кассандры. См. https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565 .
Не понимаю, почему люди любят строить сложные ненадежные системы из говна и палок вместо использования готовых, простых и надежных решений.
Не понимаю, почему люди любят строить сложные ненадежные системы из говна и палок вместо использования готовых, простых и надежных решений.
увы - из строя выходят диски даже у гугла
AV
Mikhail Malinovkin
всем привет. подскажите плз можно ли так сделать в связке prometheus+victoriametrics, в прометей данные хранятся за 2 дня, в виктории за месяц, чтобы когда в графане читаем за 2 дня, читалось с бд прометея, а если за неделю или за месяц , то с виктории, при этом не изменяя data source? подскажите куда копнуть
А зачем читать из прома данные за последние два дня? Ведь все эти данные уже есть в вм. Значит, оттуда можно читать данные за любой период без привоечения прома
MM
А зачем читать из прома данные за последние два дня? Ведь все эти данные уже есть в вм. Значит, оттуда можно читать данные за любой период без привоечения прома
Раньше было настроено ,что за 2 дня в проме, остальное из инфлюкса, инфлюкс выкинул, постави Викторию, за что спасибо, а так хотел делать на момент обновления виктории, но ребята подсказали что Прометей дольет потом данные недостающие
DZ
Может я отстал от жизни, а разве можно насетапить пачку машин с GCP, раскидать их по AZ и рандомно херачить их каким нить chaos monkey демоном имея при этом 100% доступность диска?
VS
Замените слово "кассандра" на "gcp persistent disk", а "кортекс" на "викторияметрикс". Получите справедливое утверждение про вм, при том, что gcp диски намного проще в настройке и сопровождении по сравнению с кассандрой, и они вообще не выходят из строя, в отличие от кассандры. См. https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565 .
Не понимаю, почему люди любят строить сложные ненадежные системы из говна и палок вместо использования готовых, простых и надежных решений.
Не понимаю, почему люди любят строить сложные ненадежные системы из говна и палок вместо использования готовых, простых и надежных решений.
есть один момент - к сожалению на практике репликация и failover лучше работает на уровне приложения, а не какое-то generic решение. Ибо в случаи с persistent disk'ами - есть ситуации когда у тебя у сервиса на мониторинг будет outage, а также переаттач диска к другой VM если что - это не супер быстро
VS
а также не решает проблему cross-AZ или cross-region доступности в общем. Ну и цена конечно
VS
в смысле галочка "реплицировать куда-то там" - будет стоить денег
DZ
А, переаттач. Ну так зачем хер с пальцем сравнивать. Я думал какая то магия есть. 🙂
VS
А, переаттач. Ну так зачем хер с пальцем сравнивать. Я думал какая то магия есть. 🙂
теоретически VM смигрирует если хост дохнет, но это не поможет от zonal outage
DZ
Ну то понятно.
VS
точнее будет рестарт и если приложение не делало sync то какие-то данные из кэша до диска не доедут (и это не data loss с точки зрения провайдера, провайдер на сетевые диски гарантирует что все что посинкано - доступно)
DZ
Но миграция то не мгновенная. А реплик у ВМ нет.
VS
короче есть ньюансы
VS
Но миграция то не мгновенная. А реплик у ВМ нет.
в случаи host error'ов она чаще работает чем не работает
VS
а так ну считай что у тебя в любой момент дернут ресет
VS
то есть минута-две недоступности пока все бутается и стартует + потеря всего что не засинкано