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

Привет, меня зовут Вера Сивакова. Я работаю с ключевыми партнёрами Яндекс.Кассы — подключаю большие магазины и сервисы, запускаю проекты и езжу на встречи по всему миру. В общем, слежу, чтобы всё было хорошо.

Каждый сотрудник Яндекс.Денег раз в год может сменить род деятельности — выбрать какой-нибудь отдел и поработать там несколько дней. Поэтому месяц назад и я села в Сапсан и приехала в Петербург. Там работает отдел мониторинга, который тоже следит, чтобы у 90 тысяч сайтов, подключенных к Кассе, всё было хорошо, — и мы решили объединить силы.

Десять человек на 90 тысяч сайтов: как не сойти с ума - 1
Как не сойти с ума? Точно не так (источник: reddit.com)

Это рассказ о том, как у нас устроен мониторинг, и чему я научилась за пару дней в другом департаменте.

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

Kubernetes в production: сервисы - 1Полгода назад мы закончили миграцию всех наших stateless сервисов в kubernetes. На первый взгляд задача достаточно простая: нужно развернуть кластер, написать спецификации приложений и вперед. Из-за одержимости в вопросе обеспечения стабильности в работе нашего сервиса пришлось сразу начать разбираться с тем, как работает k8s и тестировать различные сценарии отказов. Больше всего вопросов у меня возникало ко всему, что касается сети. Один из таких "скользких" моментов — работа сервисов (Services) в kubernetes.

В документации нам говорят:

  • выкатите приложение
  • задайте liveness/readiness пробы
  • создайте сервис
  • дальше все будет работать: балансировка нагрузки, обработка отказов итд.

Но на практике все несколько сложнее. Давайте посмотрим, как оно работает на самом деле.

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

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.
Читать полностью »

Да, я тоже бываю дебилом. Но такого я от себя не ожидал. Вроде бы «не первый год замужем». Вроде бы читал кучу умных статей об отказоустойчивости, избыточности и т.п., что-то разумное когда-то написал даже сам тут. Свыше 10 лет являюсь CEO хостинг-провайдера работающего под брэндом ua-hosting.company и предоставляющего услуги хостинга и аренды серверов в Нидерландах, США, а буквально неделю назад и в Великобритании (не спрашивайте, почему название ua, ответ можете найти в нашей автобиографической статье), предоставляем клиентам решения различной степени сложности, иногда такой, что даже сами затрудняемся разобраться в том, что сотворили.

Но блин… Сегодня я превзошёл сам себя. Мы сами себе полностью снесли сайт и биллинг, со всеми транзакциями, данными клиентов об услугах и прочим и в этом виноват был я, я сам сказал «удаляй». Некоторые из Вас уже заметили это. Это случилось сегодня, в пятницу в 11:20 по восточному североамериканскому времени (EST). Причём наш сайт и биллинг размещены были не на одном сервере, и даже не в облаке, мы ушли из облака дата-центра 2 месяца назад в пользу нашего собственного решения. Всё это размещалось на отказоустойчивом гео-кластере из двух виртуальных серверов — нашего нового продукта, VPS (KVM) c выделенными накопителями, НЕЗАВИСИМЫХ VPS, которые располагались на двух континентах — в Европе и в США. Один в Амстердаме, а другой в Манассасе, под Вашингтоном, тем, что D.C. В двух надёжнейших дата-центрах. Контент на которых постоянно и в реальном времени дублировался, а отказоустойчивость основана на обычном кластере DNS, запросы могли приходить на любой из серверов, любой выполнял роль MASTER, и в случае недоступности брал на себя задачи второго.

Я думал, что это может убить только метеорит, ну или ещё что-то подобное глобальное, что может вывести из строя два дата-центра одновременно. Но всё оказалось проще.Читать полностью »

Исследование устойчивости национальных сегментов сети Интернет за 2018 год - 1

Данное исследование объясняет каким образом отказ одной автономной системы (AS) влияет на глобальную связность отдельного региона, особенно в том случае когда речь идет о крупнейшем провайдере интернета (ISP) данной страны. Связность интернета на сетевом уровне обусловлена взаимодействием между автономными системами. По мере увеличения количества альтернативных маршрутов между AS возникает устойчивость к отказам и повышается стабильность интернета в данной стране. Однако, некоторые пути становятся более важными по-сравнению с остальными и наличие как можно большего числа альтернативных маршрутов в итоге является единственным жизнеспособным способом обеспечить надежность системы (в смысле AS).

Глобальная связность любой AS, независимо от того, представляет ли она второстепенного поставщика интернета или международного гиганта с миллионами потребителей услуг, зависит от количества и качества его путей к Tier-1 провайдерам. Как правило, Tier-1 подразумевает международную компанию, предлагающую глобальную услугу IP-транзита и подключение к другим Tier-1 операторам. Тем не менее, внутри данного элитного клуба нет обязательства поддерживать такую связь. Только рынок может придать мотивацию таким компаниям безоговорочно соединяться друг с другом, обеспечивая высокое качество обслуживания. Достаточный ли это стимул? Мы ответим на этот вопрос ниже в секции, посвященной связности IPv6.

Если провайдер интернета теряет связь с хотя бы одним из собственных Tier-1 соединений, он, вероятнее всего, окажется недоступен в некоторых частях Земли.
Читать полностью »

Начиная с 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 вызовов, а резервный (пассивный) узел мониторит активный хост. При выходе из строя активного хоста (независимо от причины), пассивный хост включается в работу примерно с того же состояния. Механизм определения выхода из строя активного хоста зависит от настроек на пассивном хосте и рассматривается ниже.Читать полностью »


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