Рубрика «high availability» - 2

в 8:39, , рубрики: cloud, high availability, postgresql, Администрирование баз данных, Блог компании Mail.Ru Group, Настройка Linux, Серверное администрирование

Как мы построили надёжный кластер PostgreSQL на Patroni - 1

На сегодняшний день высокая доступность сервисов требуется всегда и везде, не только в крупных дорогих проектах. Временно недоступные сайты с сообщением «Извините, проводится техническое обслуживание» ещё встречаются, но обычно вызывают снисходительную улыбку. Прибавим к этому жизнь в облаках, когда для запуска дополнительного сервера нужен лишь один вызов к API, причем думать о «железной» эксплуатации не надо. И уже не остается оправданий, почему критичная система не была сделана надежно с использованием кластерных технологий и резервирования.

Мы расскажем, какие решения мы рассматривали для обеспечения надёжности баз данных в своих сервисах и к чему пришли. Плюс демо с далеко идущими выводами.
Читать полностью »

в 6:43, , рубрики: 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.

Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации - 1

TL;DR

  • Всё получилось (не без костылей, о них и статья).
  • Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
  • Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

Читать полностью »

в 17:10, , рубрики: consul, devops, github, haproxy, high availability, mysql, Блог компании Southbridge, Серверное администрирование, системное администрирование

GitHub использует MySQL в качестве основного хранилища данных для всего, что не связано с git, поэтому доступность MySQL имеет ключевое значение для нормальной работы GitHub. Сам сайт, интерфейс API на GitHub, система аутентификации и многие другие функции требуют доступа к базам данных. Мы используем несколько кластеров MySQL для обработки различных служб и задач. Они настроены по классической схеме с одним главным узлом, доступным для записи, и его репликами. Реплики (остальные узлы кластера) асинхронно воспроизводят изменения главного узла и обеспечивают доступ для чтения.

Доступность главных узлов критически важна. Без главного узла кластер не поддерживает запись, а это значит, что нельзя сохранить необходимые изменения. Фиксация транзакций, регистрация проблем, создание новых пользователей, репозиториев, обзоров и многое другое будет просто невозможно.

Для поддержки записи необходим соответствующий доступный узел – главный узел в кластере. Впрочем, не менее важна возможность определить или обнаружить такой узел.

В случае отказа текущего главного узла важно обеспечить оперативное появление нового сервера ему на замену, а также иметь возможность быстро оповестить об этом изменении все службы. Общее время простоя складывается из времени, уходящего на обнаружение сбоя, отработку отказа и оповещение о новом главном узле.

Высокая доступность MySQL в GitHub - 1Читать полностью »

в 11:38, , рубрики: devops, etcd, high availability, kubernetes, multimaster, кластер, системное администрирование

Эта статья является свободной интерпретацей официального руководства Creating Highly Available Clusters with kubeadm для Stacked control plane nodes. Мне не нравятся сложный язык и примеры использованные в нем, поэтому я написал свое руководство.

Если у вас появятся какие-либо вопросы или вам будет что-то неясно, обратитесь к официальной документации или спросите Google. Все этапы описаны здесь в максимально простой и сдержанной форме.

Читать полностью »

в 6:46, , рубрики: devops, high availability, kubernetes, Блог компании Флант, распределенные системы, системное администрирование

Прим. перев.: Оригинальная статья была написана техническим писателем из Google, работающим над документацией для Kubernetes (Andrew Chen), и директором по software engineering из SAP (Dominik Tornow). Её цель — доступно и наглядно объяснить основы организации и реализации high availability в Kubernetes. Нам кажется, что у авторов получилось, поэтому мы рады поделиться переводом.

Как обеспечивается высокая доступность в Kubernetes - 1

Kubernetes — движок оркестровки контейнеров, созданный для запуска контейнеризированных приложений на множестве узлов, которые обычно называют кластером. В этих публикациях мы используем подход системного моделирования с целью улучшить понимание Kubernetes и его нижележащих концепций. Читающим рекомендуется уже иметь базовое представление о Kubernetes.

Kubernetes — масштабируемый и надёжный движок оркестровки контейнеров. Масштабируемость здесь определяется отзывчивостью в присутствии нагрузки, а надёжность — отзывчивостью в присутствии отказов.Читать полностью »

в 15:53, , рубрики: drbd, drbd9, high availability, iscsi, istgt, LVM, open source, opennebula, proxmox, высокая доступность, высокая производительность, контейнеры, Облачные вычисления, облачные технологии, СХД, хранение данных, хранилища данных, хранилище

image

В предыдущей статье я рассмотрел возможность создания отказоустойчивого NFS-сервера с помощью DRBD и Proxmox. Получилось довольно неплохо, но не будем останавливаться на достигнутом и теперь постараемся "выжать все соки" из нашей хранилки.

В этой статье я расскажу как подобным образом создать отказоустойчивый iSCSI-таргет, который при помощи LVM мы будем нарезать на маленькие кусочки и использовать под виртуальные машины.

Именно такой подход позволят снизить нагрузку и повысить скорость доступа к данным в несколько раз, это бывает особенно выгодно когда не требуется конкурентный доступ к данным, например в случае когда вам нужно организовать хранилище под виртуальные машины.

Читать полностью »

в 9:25, , рубрики: continuous delivery, continuous integration, devops, docker, high availability, kubernetes, RabbitMQ, Блог компании EastBanc Technologies, высокая производительность, Микросервисная архитектура, микросервисы, оркестрация, отказоустойчивость

При микросервисной организации приложения существенная работа ложится на механизмы интеграционной связи микросервисов. Причем эта интеграция должна быть отказоустойчива, с высокой степенью доступности.

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.

image

До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

Мы опишем итоговую конфигурацию целиком, попутно комментируя происходящее.
Читать полностью »

в 10:56, , рубрики: cluster, dbms, high availability, postgres, postgresql, базы данных, Блог компании Postgres Professional, кластер, СУБД

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!

Кластер pacemaker-corosync без валидола - 1
А ведь могло быть по-другому. Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать. Нет надобности срочно ехать на работу и восстанавливать сервер БД. Выяснение причин сбоя и работы по восстановлению спокойно переносятся на рабочий понедельник.

Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL. Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync.

Читать полностью »

в 6:37, , рубрики: backup, DSM, high availability, LUN, NAS, raid, SAN, Synology, xpenology, виртуализация, высокая производительность, гибридное хранилище, кластер, резервирование, резервное копирование, сервер, СХД, хранение данных, хранилища данных

Гибридное хранилище для дома «из коробки» и возможности High Availability от Synology - 1Несколько лет назад, при выборе первого хранилища для дома, я смотрел в сторону «коробочных решений» по причине не особой осведомлённости в построении системы хранения на базе открытого ПО и обычного ПК. В тот раз выбор пал на 2-дисковую NAS — Shuttle KD20. Хранилище было компактным и тихим. RAID1 обеспечивал необходимую надёжность, а потребности в высокой производительности и расширенном функционале на тот момент не было. Этот NAS проработал почти 4 года, пока в один прекрасный момент не накрылась линия питания вентилятора. Диски раскалились до 60 градусов и чудом выжили. Я запаял вентилятор напрямую к материнке, но стал подбирать вариант на замену. В качестве второй NAS я выбрал 4-дисковую Synology. Задачи оставались те же, поэтому в функционал DiskStation Manager (DSM) я особо не вникал. Это продолжалось до тех пор, пока я не решил установить домашнее видеонаблюдение на несколько каналов. Не смотря на то, что Synology имеет собственный сервис видеонаблюдения, я остановился на Macroscop — была потребность в расширенном функционале и серьёзной аналитике. На своё счастье, я обнаружил в DSM новый пакет Virtual Machine Manager — гипервизор, с помощью которого я создал виртуальную машину и установил на неё Windows и Macroscop. На запись система работала нормально, встроенный Pentium 1,6 ГГц с трудом, но успевал отрабатывать задачи СХД и виртуальной машины. Но как только активировалась какая-либо аналитика — сервис отваливался по перегрузке процессора. В результате, я был вынужден начать поиски отдельного бюджетного Windows-девайcа с адекватной производительностью для реализации сервера видеонаблюдения, так как Synology необходимого уровня стоит недёшево. В тот самый момент я в очередной раз наткнулся в сети на статьи, посвящённые установке DSM на обычное железо и мой проект XPenology начался…
Читать полностью »

в 22:34, , рубрики: high availability, mysql, nosql, uber, высокая производительность

Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL

By Jakob Holdgaard Thomsen
January 12, 2016

https://eng.uber.com/schemaless-part-one/

image

Проектирование Schemaless хранилища данных Uber Engineering с использованием MySQL. Это первая часть из трех частей серии статей о Schemaless хранилище данных.

В Project Mezzanine мы описали, как мы перенесли данные о поездках Uber из одного экземпляра Postgres в Schemaless — наше высокопроизводительное и надежное хранилище данных. В этой статье описывается его архитектура, роль в инфраструктуре Uber и история проектирования.
Читать полностью »

123...5
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js