Всем привет! Меня зовут Максим, я руководитель одной из групп эксплуатации инфраструктурных сервисов в Ozon. Наша команда занимается поддержкой и развитием нескольких базовых сервисов компании, одним из которых, по историческим причинам, является сервис разрешения доменных имен (DNS).
Рубрика «high availability»
Через реки, через лес прямо к PowerDNS
2023-03-15 в 10:36, admin, рубрики: BGP, DNS, EDNS, high availability, maintenance, multi-dc, ozon tech, postgresql, powerdns, recursor, Блог компании Ozon Tech, распределенные системы, системное администрированиеЧетвёртая будет? Как мы развернули ещё одну зону доступности в нашем ЦОД
2022-12-02 в 10:31, admin, рубрики: ethernet, high availability, infiniband, Блог компании КРОК, дата-центр, зона доступности, инфраструктура как код, облако крок, Облачные вычисления, облачные сервисы, Сетевые технологии, цодВ начале года мы рассказали о том, как подключали третью зону доступности в нашем облаке: почему вернулись к Ethernet, как развёртывали сети и собирали честный кворум для распределённых сервисов.
Босяцкий кластер высокой доступности
2022-08-22 в 1:01, admin, рубрики: DNS, failover, gtm, high availability, high availability clusters, high performance, keepalived, load balancing, nginx, vrrp, высокая производительность, Сетевые технологии, системное администрированиеПорой нам бывает нужно добавить избыточность какому-то сервису, который оказался публичной точкой входа в нашу инфраструктуру. Например, представьте, что мы хотим добавить второй балансировщик для высокой доступности. При этом балансировщики находятся на границе нашей сети и пересылают трафик доступным бэкенд-серверам.
Читать полностью »
Лучшие практики для деплоя высокодоступных приложений в Kubernetes. Часть 1
2021-03-03 в 13:06, admin, рубрики: devops, high availability, kubernetes, Блог компании Флант, системное администрированиеРазвернуть в Kubernetes приложение в минимально рабочей конфигурации нетрудно. Но когда вы захотите обеспечить своему приложению максимальную доступность и надежность в работе, вы неизбежно столкнётесь с немалым количеством подводных камней. В этот статье мы попытались систематизировать и ёмко описать самые важные правила для развертывания высокодоступных приложений в Kubernetes.
Истории аварий с Patroni, или Как уронить PostgreSQL-кластер
2020-03-11 в 8:58, admin, рубрики: auto failover, consul, high availability, patroni, postgresql, Администрирование баз данных, Анализ и проектирование систем, Блог компании Конференции Олега Бунина (Онтико), высокая производительностьВ PostgreSQL нет High Availability из коробки. Чтобы добиться HA, нужно что-то поставить, настроить — приложить усилия. Есть несколько инструментов, которые помогут повысить доступность PostgreSQL, и один из них — Patroni.
На первый взгляд, поставив Patroni в тестовой среде, можно увидеть, какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Но на практике в production-среде не всегда всё происходит так красиво и элегантно. Data Egret начали использовать Patroni еще в конце 2018 года и накопили определенный опыт: как его диагностировать, настраивать, а когда вовсе не полагаться на автофейловер.
На HighLoad++ Алексей Лесовский обстоятельно, на примерах и с разбором логов рассказал о типовых проблемах, возникающих при работе с Patroni, и best practice для их преодоления.
В статье не будет: инструкций по установке Patroni и примеров конфигураций; проблем за пределами Patroni и PostgreSQL; историй, основанных на чужом опыте, а только те проблемы, с которыми в Data Egret разобрались сами.
Читать полностью »
Orchestrator и VIP как HA-решение для кластера MySQL
2020-03-04 в 12:35, admin, рубрики: database, devops, high availability, highload, mysql, Orchestrator, Percona, бд mysql, Блог компании СитимобилВ Ситимобил мы используем базу данных MySQL в качестве основного хранилища постоянных данных. У нас есть несколько кластеров баз данных под различные сервисы и цели.
Постоянная доступность мастера является критическим показателем работоспособности всей системы и ее отдельных частей. Автоматическое восстановление кластера в случае отказа мастера сильно снижает время реагирования на инцидент и время простоя системы. В этой статье я рассмотрю схему обеспечения высокой доступности (HA) кластера MySQL на основе MySQL Orchestrator и виртуальных IP адресов (VIP).
Эффективное хранение сотен миллионов маленьких файлов. Self-Hosted решение
2020-01-17 в 11:23, admin, рубрики: bolt, Go, high availability, nginx reverse proxy, serverless, storage, хранение данных
Уважаемое сообщество, эта статья будет посвящена эффективному хранению и выдаче сотен миллионов маленьких файлов. На данном этапе предлагается конечное решение для POSIX совместимых файловых систем, в том числе кластерных, и вроде бы даже уже без костылей.
Поэтому для этой цели я написал свой собственный специализированный сервер.
По ходу реализации этой задачи удалось решить основную проблему, попутно добиться экономии дискового пространства и оперативной памяти, которую нещадно потребляла наша кластерная файловая система. Собственно такое количество файлов вредно для любой кластерной файловой системы. Читать полностью »
Архитектура AERODISK vAIR или особенности национального кластеростроения
2019-11-11 в 2:00, admin, рубрики: Aerodisk, erasure codes, Erasure Coding, HCI, high availability, hyperconverged, hyperconverged cluster, IOPS, linux, replication, SAN, scale-out, storage, Блог компании AERODISK, гиперконвергентная система, гиперконвергентность, гиперконвергентные платформы, гиперконвергентные системы, гиперконвергенция, импортозамещение, отказоустойчивость, репликация, российское оборудование, Серверное администрирование, система хранения данных, системное администрирование, СХД, хранение данных, хранилища данных
Привет, Хабровчане! Мы продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье речь пойдет об архитектуре данной системы. В прошлой статье мы разобрали нашу файловую систему ARDFS, а в данной статье пройдёмся по всем основным программным компонентам, из которых состоит vAIR, и по их задачам.
Как мы построили надёжный кластер PostgreSQL на Patroni
2019-05-22 в 8:39, admin, рубрики: cloud, high availability, postgresql, Администрирование баз данных, Блог компании Mail.Ru Group, Настройка Linux, Серверное администрирование
На сегодняшний день высокая доступность сервисов требуется всегда и везде, не только в крупных дорогих проектах. Временно недоступные сайты с сообщением «Извините, проводится техническое обслуживание» ещё встречаются, но обычно вызывают снисходительную улыбку. Прибавим к этому жизнь в облаках, когда для запуска дополнительного сервера нужен лишь один вызов к API, причем думать о «железной» эксплуатации не надо. И уже не остается оправданий, почему критичная система не была сделана надежно с использованием кластерных технологий и резервирования.
Мы расскажем, какие решения мы рассматривали для обеспечения надёжности баз данных в своих сервисах и к чему пришли. Плюс демо с далеко идущими выводами.
Читать полностью »
Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации
2019-01-24 в 6:43, admin, рубрики: devops, high availability, linux, postgresql, replication, Администрирование баз данных, Блог компании True Engineering, высокая производительность, отказоустойчивостьУ нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.
Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.
Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.
Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с помощью стороннего плагина под названием pglogical.
В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.
TL;DR
- Всё получилось (не без костылей, о них и статья).
- Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
- Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).