Size: a a a

Церковь метрик

2020 February 12

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Я в курсе что такое персистентный диск, спасибо. Мы уже вроде по 10 кругу обсудили выше что это не дает и не может дать 100% доступности инстанса а без репликации не 100% доступный инстанс означает не 100% доступный сервис. Зачем одно и то же 100 раз мусолить.
источник

BG

Bogdan (SirEdvin) Gladyshev in Церковь метрик
Я так понимаю, то, что это вендор-лок в целом никого не волнует? Чувствую себя немного ущербно в такой дисскусии, где подразумевается, что у каждого инфраструктура в google cloud
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Еще раз могу процитировать себя же, может @valyala пропустил - https://t.me/metrics_ru/132062
Telegram
Denys 💛📈 💫 Zhdanov in Церковь метрик
тогда могу развернуть так.
"В Кортексе данные хранятся в Кассандре, которую можно (при всех ее других минусах) настроить под любую консистентность и потерять хоть всю AZ целиком.
ВМ не имеет репликации и настраиваемой консистентности, поэтому в вопросах надежности полагается только на GCP персистентные диски
(или аналогичное решение у других клауд провайдеров). Это решение в принципе достаточно надежно, но стоит понимать что не обеспечивает
100% доступности при проблемах с инфраструктурой провайдера (потеря виртуалок, zone outage). Также использование персистентных GCP дисков может быть ощутимо дороже обычных или даже облачных SSD дисков. Ну и использование только GCP дисков для HA не дает возможности развернуть ВМ в HA режиме on-premise, на собственном железе или в частном облаке".
Не понимаю, почему люди любят строить простые но ненадежные системы из говна и палок вместо использования готовых, надежных и проверенных временем решений (хоть и за счет увеличенной сложности). :trollface:
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Странно что приходится обьяснять в 2020 году что такое cloud ready software, и как нужно масштабировать сервис в облаке.
источник

AV

Aliaksandr Valialkin in Церковь метрик
Vladimir Smirnov
есть один момент - к сожалению на практике репликация и failover лучше работает на уровне приложения, а не какое-то generic решение. Ибо в случаи с persistent disk'ами - есть ситуации когда у тебя у сервиса на мониторинг будет outage, а также переаттач диска к другой VM если что - это не супер быстро
Согласен по поводу временной недоступности части данных при выходе из строя физическлй машины, на котлрой работает инстанс. Но не согласен насчет длительности восстановления. Обычно в таких случаях клауд-провайдеры автоматом переносят инстансы на рабочую физическую машину. Время переезда на новый инстанс равно времени старта операционки плюс время запуска вм. Суммарное время составляет от силы минуту. Теперь вспомните, как часто в клауде падали ваши инстансы из-за физических поломок железных серверов, на которых они работали. А затем сравните это с частотой и длительностью поломок разных кластеров, управляемых вами вручную, типа кассандры.
источник

AV

Aliaksandr Valialkin in Церковь метрик
Vladimir Smirnov
а также не решает проблему cross-AZ или cross-region доступности в общем. Ну и цена конечно
Если что, то gcp persistent disk'и поддерживают cross-dc репликацию. Т.е. при недоступности одного из датацентров диски продолжают нормально работать в другом дц
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Ох
источник

VS

Vladimir Smirnov in Церковь метрик
Aliaksandr Valialkin
Если что, то gcp persistent disk'и поддерживают cross-dc репликацию. Т.е. при недоступности одного из датацентров диски продолжают нормально работать в другом дц
Поддерживает, только цена у этой фичи есть (в деньгах)
источник

VS

Vladimir Smirnov in Церковь метрик
Aliaksandr Valialkin
Согласен по поводу временной недоступности части данных при выходе из строя физическлй машины, на котлрой работает инстанс. Но не согласен насчет длительности восстановления. Обычно в таких случаях клауд-провайдеры автоматом переносят инстансы на рабочую физическую машину. Время переезда на новый инстанс равно времени старта операционки плюс время запуска вм. Суммарное время составляет от силы минуту. Теперь вспомните, как часто в клауде падали ваши инстансы из-за физических поломок железных серверов, на которых они работали. А затем сравните это с частотой и длительностью поломок разных кластеров, управляемых вами вручную, типа кассандры.
При условии что фс не побилась. Плюс данные какие то того и ещё поди потом найди что где куда
источник

AV

Aliaksandr Valialkin in Церковь метрик
Vladimir Smirnov
точнее будет рестарт и если приложение не делало sync то какие-то данные из кэша до диска не доедут (и это не data loss с точки зрения провайдера, провайдер на сетевые диски гарантирует что все что посинкано - доступно)
К счастью, вм скидывает данные на диск каждую секунду. Т.е. в худшем случае потеряется последняя секунда данных. См. https://medium.com/@valyala/wal-usage-looks-broken-in-modern-time-series-databases-b62a627ab704
источник

AV

Aliaksandr Valialkin in Церковь метрик
Vladimir Smirnov
и хотят что-то что не будет требовать дорогих решений и будет работать на любом разумном хостинге (on-prem на железе, gcp, aws, azure, digital ocean, ...) и позволит переживать локальные аутейджи (зона или стойка отъехала)
Да, я тоже хочу такую репликацию. К сожалению, сам до такой пока не додумался. Из живых примеров есть только gcp persistent disk
источник

AV

Aliaksandr Valialkin in Церковь метрик
Denys 💛📈 💫 Zhdanov
тогда могу развернуть так.
"В Кортексе данные хранятся в Кассандре, которую можно (при всех ее других минусах) настроить под любую консистентность и потерять хоть всю AZ целиком.
ВМ не имеет репликации и настраиваемой консистентности, поэтому в вопросах надежности полагается только на GCP персистентные диски
(или аналогичное решение у других клауд провайдеров). Это решение в принципе достаточно надежно, но стоит понимать что не обеспечивает
100% доступности при проблемах с инфраструктурой провайдера (потеря виртуалок, zone outage). Также использование персистентных GCP дисков может быть ощутимо дороже обычных или даже облачных SSD дисков. Ну и использование только GCP дисков для HA не дает возможности развернуть ВМ в HA режиме on-premise, на собственном железе или в частном облаке".
Не понимаю, почему люди любят строить простые но ненадежные системы из говна и палок вместо использования готовых, надежных и проверенных временем решений (хоть и за счет увеличенной сложности). :trollface:
Так ок, кроме предложения про стоимость дисков. Для вм нормально подходят обычные hdd-based pd, которые стоят $40 в месяц за терабайт
источник

ЕО

Евгений Омельченко in Церковь метрик
Мне кажется, что программисту бессмысленно объяснять оперейшонс поинт оф вью. Они все вращают многомерных сферической коней в вакууме. Попытка им объяснить что такое ноги только прибавляет размерность их сфере
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
А я хочу такую самоуверенность, чтобы спорить с полным чатом (а может и интернетом) инженеров с суммарным продакшн опытом эксплуатации систем в 100500 лет почему они все дураки и не переехали дружно на gcp...
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Евгений Омельченко
Мне кажется, что программисту бессмысленно объяснять оперейшонс поинт оф вью. Они все вращают многомерных сферической коней в вакууме. Попытка им объяснить что такое ноги только прибавляет размерность их сфере
+
источник

AV

Aliaksandr Valialkin in Церковь метрик
Serge Yuriev
я в результате сделал через quantile (by job) (label_replace(metric) or label_replace(metric))
гистограмму тоже попробую - может оно будет интереснее :)
quantile - это агрегирующая функция вроде sum, count, max, min и т.п. Она учитывает только "мгновенные" значения по рядам в каждой возвращаемой точке. Она не учитывает все точки в рядах, а также не учитывает значения в окне, указаемом в квадратных скобках функций вроде *_over_time. Поэтому, вполне вероятно, что вы получаете не совсем тот результат, что ожидаете.
источник

AV

Aliaksandr Valialkin in Церковь метрик
Vladimir Smirnov
вопрос №2 - что лучше - такая репликация или никакой репликации )
Лучше - переложить репликацию на надежное и беспроблемное решение вроде gcp disks :) Я успешно использовал это решение для обеспечения надежного хранения данных в кликхаусе вместо того, чтобы мучаться с репликацией, встроенной в кх, основанной на зукипере. За полтора года не было потерь или порчи данных на дисках суммарным объемом 500ТБ
источник

vk

vladimir kolobaev in Церковь метрик
Aliaksandr Valialkin
Лучше - переложить репликацию на надежное и беспроблемное решение вроде gcp disks :) Я успешно использовал это решение для обеспечения надежного хранения данных в кликхаусе вместо того, чтобы мучаться с репликацией, встроенной в кх, основанной на зукипере. За полтора года не было потерь или порчи данных на дисках суммарным объемом 500ТБ
Расскажи пожалуйста, как ты мучался с репликацией в КХ если она организуется за пол часа при первом подходе к снаряду, и работает так, что тебе вообще не приходится про нее вспоминать.
У нас 20Тб данных под репликацией + шардированием средствами КХ, мы никаких проблем не наблюдали.
Зато я могу сказать что плавное обновление инстансов без даун тайма, благодаря все той же репликации, и балансировки запросов, очень отлично себя показывают на протяжении последних 2 лет
источник

VS

Vladimir Smirnov in Церковь метрик
Aliaksandr Valialkin
Лучше - переложить репликацию на надежное и беспроблемное решение вроде gcp disks :) Я успешно использовал это решение для обеспечения надежного хранения данных в кликхаусе вместо того, чтобы мучаться с репликацией, встроенной в кх, основанной на зукипере. За полтора года не было потерь или порчи данных на дисках суммарным объемом 500ТБ
Проблема в том что за пределами gcp нет gcp persistent disk. :) И сопоставимые фичи онпрем сделать сложно
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
В gcp persistent disk видать какая то магическая репликация. Феи наверно данные носят. Или она от инопланетян досталась, с sla 100% то. Людям такое не осилить... (сорри за тролинг но я что то просто уже не могу)
источник