Рубрика «отказоустойчивость» - 4

Начиная с 3CX v15.5 SP1 мы добавили две консольные утилиты для резервного копирования и восстановления конфигурации АТС. Они используются, прежде всего, в скриптах автоматизации, либо если отсутсвует доступ к интерфейсу сервера.

Если вы обслуживаете большое количество облачных экземпляров 3CX, скрипт автоматического резервирования весьма удобен, т.к. работает из единой консоли, не требуя входа в интерфейс управления каждого сервера. Консольные утилиты доступны как в версии 3CX для Linux, так и для Windows.Читать полностью »

Как устроен современный банк? Есть бэк-офис, где выполняются разные операции, ведутся счета и отчетность. Есть мидл-офис, где принимаются решения и оцениваются риски, где оценивают кредитные риски и противодействуют мошенникам. И есть фронт-офис, где обслуживают клиентов и отвечают за их взаимодействие с банком через разные каналы.

Секреты отказоустойчивости нашего фронт-офиса - 1

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

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

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

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

image

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

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

Pure Storage ActiveCluster в связке с VMware: обзор и тестирование - 1

Не так давно компания Pure Storage анонсировали новую функциональность ActiveCluster – active/active метро кластер между хранилищами данных. Это технология синхронной репликации, при которой логический том растянут между двумя хранилищами и доступен на чтение/запись на обоих. Эта функциональность доступна с новой версией прошивки Purity//FA 5 и является абсолютно бесплатным. Также Pure Storage пообещали, что настройка растянутого кластера никогда не была еще такой простой и понятной.

В данной статье мы расскажем про ActiveCluster: из чего состоит, как работает и настраивается. Отчасти статья является переводом официальной документации. Помимо этого, мы поделимся опытом тестирования его на отказоустойчивость в VMware-окружении.
Читать полностью »

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

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

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

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

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

Сегодня мы хотели бы рассказать про один из последних проектов по созданию корпоративного центра обработки данных. Это Череповецкий ЦОД компании «ФосАгро», основное направление деятельности которой – производство фосфорсодержащих удобрений, фосфатного сырья, а также кормовых фосфатов, азотных удобрений и аммиака. В Группу «ФосАгро» входят АО «Апатит» и его Балаковский филиал, АО «ФосАгро-Череповец», АО «Метахим», ООО «ФосАгро-Транс», ООО «ФосАгро-Регион» и АО «НИУИФ». Группа является крупнейшим европейским производителем фосфорных удобрений, а также крупнейшим мировым производителем высокосортного фосфорного сырья.

Основными целями создания нового ЦОДа стали централизация серверного комплекса «ФосАгро» в одном месте, а также реорганизация ядра сети. Проект был реализован всего за четыре месяца, причем, по классической технологии – с капитальным ремонтом помещений. Как этого удалось добиться спросите вы? В первую очередь, благодаря эффективно работающей команде, своевременной поставке оборудование, согласованному выполнению монтажа различных подсистем. Ну и, конечно, помог грамотный выбор технических решений. Подробности – ниже.
Читать полностью »

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

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

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

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


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

В кластере Kubernetes нода может умереть или перезапуститься.

Инструменты вроде Kubernetes обеспечивают высокую доступность, спроектированы для надёжного функционирования и автоматического восстановления в подобных сценариях, и Kubernetes действительно прекрасно со всем этим справляется.
Улучшая надёжность Kubernetes: как быстрее замечать, что нода упала - 1
Однако вы можете заметить: когда нода падает, поды сломанной ноды на протяжении какого-то времени всё ещё запущены и получают запросы, которые уже не выполняются.

И по умолчанию это время, как мне кажется, слишком велико — его можно уменьшить. На него влияют несколько параметров, настраиваемых в Kubelet и Controller Manager.
Читать полностью »

«Сложную архитектуру очень просто сделать» — интервью с Олегом Анастасьевым из Одноклассников - 1

Знакомьтесь, Олег Анастасьев — ведущий разработчик Одноклассников, спикер на конференциях по Java и Cassandra, эксперт в области распределенных и отказоустойчивых систем. С Олегом мы поговорили о следующем:

  • Что не так с термином «архитектор»
  • Зачем Одноклассникам 11 000 серверов
  • Как выглядят учения по ликвидации аварий
  • Что такое «Правило большого З»
  • Как в Одноклассниках используют Cassandra
  • В чём для современной компании сложности с размещением кода в Open Source
  • Как в Одноклассниках работают с Big Data

Как всегда, под катом — полная текстовая расшифровка беседы.
Читать полностью »

Приветствую всех читательов. Мой первый опыт написания статей на Хабре, так что любая конструктивная критика приветствуется. Написать решил только лишь потому, что недавно столкнулся с задачей, решения которой «в лоб» не нашел.

Суть задачи в том, что в большой организации нужен был отказоустойчивый DHCP-сервер, с dhcp-relay и возможностью быстро синхронизировать конфигурацию. Основной момент, что в большинстве найденных мной руководствах рассматривается либо вариант failover, либо dhcp-relay и нигде оба варианта не рассматривались вместе да ещё и с удобным методом синхронизации конфигурации. Вдруг кому моя статья немного поможет?
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js