Рубрика «кластер»

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

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

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

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

«А оно там делает магию»
кто-то из тех, кого я удалённо консультировал по Эластику.

Я всегда говорю, что верю в три вещи: мониторинг, логи и бэкапы.

Тема про то, как мы собираем и храним логи, достаточно полно была раскрыта в предыдущих статьях, тема про бэкапы в Elasticsearch — совсем отдельная история, поэтому в этой, возможно заключительной, статье цикла я расскажу как происходит мониторинг моего любимого кластера. Это не очень сложно (и не требует использования дополнительных плагинов и сторонних сервисов) — ибо REST API, предоставляемое самим Elasticsearch простое, понятное и удобное в использовании. Всего-то надо немного углубиться в его внутреннее устройство, понять, что означают все эти метрики, пулы тредов, веса распределения шардов по нодам, настройки очередей — и не останется никаких вопросов о том, что же за «магию» эластик делает прямо сейчас.

Мониторинг Elasticsearch без боли и страданий - 1

На недавней конференции Highload++ 2017 я рассказал о том, как строил кластер своей мечты, и говорил, что недостаточно просто построить сервис. Критически важно в любой момент знать, в каком он состоянии, причём контроль обязательно должен быть многоуровневым. Разбудите меня посреди ночи (отделу мониторинга привет!) — и через две минуты я буду знать, в каком состоянии находится кластер. Причём одна минута из двух уйдёт на подключение к корпоративному VPN и логин в Zabbix.
Читать полностью »

Здравствуйте!

В данной публикации я хотел бы рассказать о кластере Kubernetes с высокой доступностью (HA).

image

Оглавление:

  1. Вступление
  2. Список используемого софта
  3. Список и назначение хостов
  4. Принцип работы и развертывания
  5. Подготовка ОС к развертыванию. Установка docker, kubeadm, kubelet и kubectl
  6. Подготовка конфигурационного скрипта
  7. Создание etcd кластера
  8. Инициализация мастера с помощью kibeadm
  9. Настройка CIDR
  10. Инициализация остальных мастернод
  11. Настройка keepalived и виртуального IP
  12. Добавление рабочих нод в кластер
  13. Дополнительно

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

Splunk Distributed Search. Или как построить Indexer кластер на Splunk? - 1

Нам часто задают вопрос, как развернуть кластер на Splunk. У многих пользователей в процессе эксплуатации возникает потребность перехода от standalone к конфигурации кластера, которая обеспечивает устойчивую систему хранения и индексации данных, а также постоянную доступность данных, которая не будет зависеть от сбоев в работе оборудования. И поэтому, в рамках данной статьи мы расскажем, как развернуть Indexer кластер на Splunk, который позволит постоянно иметь доступ ко всем хранящимся данным, даже если упадет один из индексеров.
Читать полностью »

Отказоустойчивый кластер 3CX представляет собой два реплицируемых сервера АТС. Когда основной сервер выходит из строя, в работу включается сервер-реплика, минимизируя время отказа телефонии. В этой статье мы рассмотрим, как правильно конфигурировать отказоустойчивость АТС 3CX.

Лицензирование

Для использования отказоустойчивости вам потребуется одна лицензия Enterprise (ENT) или Professional (PRO). В лицензии ENT установлено время жизни (TTL) А-записи FQDN сервера 3CX в 5 минут. В лицензии PRO TTL А-записи установлено в 6 часов. Это значит, что в редакции PRO время аварийного переподключения IP-телефонов, клиентов 3CX, 3CX SBC и веб-клиента будет значительно выше.

Реализация отказоустойчивости

В 3CX используется принцип активного-пассивного кластера с репликацией конфигурации раз в минимум 24 часа. Основной (активный) узел выполняет обработку VoIP вызовов, а резервный (пассивный) узел мониторит активный хост. При выходе из строя активного хоста (независимо от причины), пассивный хост включается в работу примерно с того же состояния. Механизм определения выхода из строя активного хоста зависит от настроек на пассивном хосте и рассматривается ниже.Читать полностью »

Гибридное хранилище для дома «из коробки» и возможности 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 начался…
Читать полностью »

Прям над ними плыло легкое облако.
— Слушай, давай поедем в Тили-мили-трямдию! — предложил Медвежонок. — Говорить по-ихнему мы умеем. Смотри, какое хорошее слово: «Трям»!
— Трям? Очень хорошее слово, — сказал Ёжик. — А что оно означает?
— Трям — по-тили-мили-трямски значит «здравствуйте!»

Облака из неведомой страны. FAQ по облачным технологиям - 1

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

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

Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных иили аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:

  • RPO (recovery point objective) – допустимая потеря данных. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.
  • RTO (recovery time objective) – допустимое время восстановления данных Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.

Часто эта пара показателей отображается в виде одномерного графика вдоль оси времени.
Но в таком одномерном графике нет самого главного, на что ориентируется бизнес – денег! О том, как рассчитывать RTO и RPO, исходя из требований бизнеса, я расскажу под катом.

Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA - 1


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

«Кубики» для магазинов: зачем реально нужна гиперконвергентность, и почему это не просто модное слово - 1
Старая инфраструктура

Есть 8 больших магазинов площадью больше 10 тысяч квадратов каждый. При каждом магазине — офис с юзерами и документооборотом. На каждой точке есть серверный узел — торговые приложения, файл-сервер, домен-контроллер, прочие сервисы. Канал связи — очень тонкий, он определён забугорным корпоративным стандартом. Его хватает ровно для административных действий и синхронизации базы с наработанным за день за целую ночь. Ни о какой синхронной или асинхронной репликации базы с дата-центром речи не идёт — только режим ночной отправки диффа. Бекап на стример. На стене висела инструкция, по которой сотрудники магазинов раз в сутки меняли картриджи.

В таких условиях мы внедряли Симпливити — один из первых проектов по внедрению решений такого класса в России. Запрос пришёл не в виде «подскажите решения», а в виде конкретной задачи «Есть столько мощности, нужен такой объём». Дальше получался либо набор из пяти дорогих железок, либо из двух дорогих, но на малознакомой шаманской Симпливити. Выбрали второе. Получилась единая инфраструктура с единым пространством и таким медленным обменом между площадками. Очень странная штука.

Сейчас расскажу, что шайтан-система делает. Забегая чуть вперёд — там и модная гиперконвергентность и главная фишка — глобальная дедупликация. Читать полностью »

В этой статье используется MathJax для рендеринга математических формул. Нужно включить JavaScript, чтобы MathJax заработал.

Многие распределённые системы хранения (в том числе Cassandra, Riak, HDFS, MongoDB, Kafka, …) используют репликацию для сохранности данных. Их обычно разворачивают в конфигурации «просто пачка дисков» (Just a bunch of disks, JBOD) — вот так, без всякого RAID для обработки сбоев. Если один из дисков в ноде отказывает, то данные этого диска просто теряются. Чтобы предотвратить безвозвратную потерю данных, СУБД хранит копию (реплику) данных где-то на дисках в другой ноде.

Самым распространённым фактором репликации является 3 — это значит, что база данных хранит три копии каждого фрагмента данных на разных дисках, подключенных к трём разным компьютерам. Объяснение этому примерно такое: диски выходят из строя редко. Если диск вышел из строя, то есть время заменить его, и в это время у вас ещё две копии, с которых можно восстановить данные на новый диск. Риск выхода из строя второго диска, пока вы восстанавливаете первый, достаточно низок, а вероятность смерти всех трёх дисков одновременно настолько мала, что более вероятно погибнуть от попадания астероида.
Читать полностью »