прикрученным по мануалу к кубу. Ничего критичного в кластере тогда не было из данных, в основном для всяких вещей, которые нестрашно потерять, использовался. Так когда у меня начались проблемы с Ceph, я понятия не имел как его дебажить и тд. Очень сложная для меня вещь была тогда.
Если сейчас брать Rook, я так понимаю я буду намного более абстрагирован от Ceph, это так?
В том-то и проблема, что ни разу
В целом легче, если понимать что от него хотеть, в твоем кейсе, ты хочешь наркомании, поэтому хз, растягивание одного стороджа на Н локаций это бред, забудь об этом
Какие best practices? Я хочу защитить все данные, что у БД, что у object storage от пожаров как было в OVH, а также от внезапной блокировки аккаунта со стороны провайдера, что обычно в таких ситуациях делают? Предполагаю что в Ceph нужно будет настроить какую-нибудь условную одностороннюю репликацию в какой-нибудь google cloud
мультиклауд других вариантов нет
Купите 3 сервака, лучше 5, поставьте в нормальный колок, остальное что ты перечислил вероятность/деньги там пропасть
Как условный Google Cloud Storage (или AWS S3) работает под капотом в случае, если я при создании выбираю не конкретный регион, а Europe, например?
Я боюсь в одном ДЦ размещать после той ситуации с OVH
в разных дц у одного провайдера тоже может подвести
Зависит от того, какие данные. Для одной бд один подход, для другой третий, для не бд отдельные
хорошо, для каждой БД я настрою репликацию в другой клауд, тут проблем нет. А как с object storage лучше поступить в случае с Rook?
Не обязательно даже репликацию, у того же постгреса есть PITR. А насчет объектного… у того же AWS s3 подразумевает eventual consistency
У него есть мульсайт на уровне s3, но гарантий нет в синхронности и это не рук,это цеф, рук просто оператор, который цеф приготовил
Обсуждают сегодня