В прошлый понедельник у нас случилась очередная крайне идиотская авария. Идиоты тут мы, если что, и сейчас я расскажу детали.
Рубрика «failover»
Я наконец-то понял, как открытость может помешать — и отчёт об аварии
2025-12-23 в 11:01, admin, рубрики: failover, rca, ruvds_статьи, авария, дизель-генераторные установки, ИБП, клиентский сервис, резервное питание, цодБосяцкий кластер высокой доступности
2022-08-22 в 1:01, admin, рубрики: DNS, failover, gtm, high availability, high availability clusters, high performance, keepalived, load balancing, nginx, vrrp, высокая производительность, Сетевые технологии, системное администрированиеПорой нам бывает нужно добавить избыточность какому-то сервису, который оказался публичной точкой входа в нашу инфраструктуру. Например, представьте, что мы хотим добавить второй балансировщик для высокой доступности. При этом балансировщики находятся на границе нашей сети и пересылают трафик доступным бэкенд-серверам.
Читать полностью »Failover: нас губит перфекционизм и… лень
2019-07-19 в 7:12, admin, рубрики: accessibility, diy или сделай сам, failover, highload, ITSumma, uptime, uptimeday, Блог компании ITSumma, доступность, инфраструктура, отказоустойчивость, резервирование, резервное копированиеЛетом традиционно снижается и покупательская активность, и интенсивность изменения инфраструктуры веб-проектов, говорит нам Капитан Очевидность. Просто потому что даже айтишники, случается, ходят в отпуск. И CТО тоже. Тем тяжелее тем, кто остаётся на посту, но сейчас не об этом: возможно, именно поэтому лето — лучший период для того, чтобы не торопясь обдумать существующую схему резервирования и составить план по её улучшению. И в этом вам будет полезен опыт Егора Андреева из AdminDivision, о котором он рассказал на конференции Uptime day.
При строительстве резервных площадок, при резервировании есть несколько ловушек, в которые можно попасть. А попадаться в них совершенно нельзя. И губит нас во всем этом, как и во многом другом, перфекционизм и… лень. Мы пытаемся сделать всё-всё-всё идеально, а идеально делать не нужно! Нужно делать только определённые вещи, но сделать их правильно, довести до конца, чтоб они нормально работали.
Failover — это не какая-то такая весёлая фановая штука «чтоб было»; это вещь, которая должна сделать ровно одно — уменьшить время простоя, чтобы сервис, компания, теряла меньше денег. И во всех методах резервирования я предлагаю думать в следующем контексте: где деньги?
«Битрикс24»: «Быстро поднятое не считается упавшим»
2019-06-06 в 13:58, admin, рубрики: amazon, Amazon Web Services, bitrix, bitrix24, failover, ITSumma, uptime, uptimeday, битрикс, Битрикс24, Блог компании ITSumma, конференции, конференция, облачные сервисы, резервирование, резервное копирование, ркн, РоскомнадзорНа сегодняшний день у сервиса «Битрикс24» нет сотен гигабит трафика, нет огромного парка серверов (хотя и существующих, конечно, немало). Но для многих клиентов он является основным инструментом работы в компании, это настоящее business-critical приложение. Поэтому падать — ну, никак нельзя. А что если падение все-таки случилось, но «восстал» сервис так быстро, что никто ничего и не заметил? И как удаётся реализовать при этом failover без потери качества работы и количества клиентов? Александр Демидов, директор направления облачных сервисов «Битрикс24», рассказал для нашего блога о том, как за 7 лет существования продукта эволюционировала система резервирования.
Ни минуты оффлайн — Выбираем промышленный LTE-роутер
2019-03-15 в 11:55, admin, рубрики: 3g, failover, gps, LTE, modbus, multiwan, mwan3, openvpn, PingPlotter, rs-232, RS-485, vrrp, Беспроводные технологии, промышленный роутер, резервирование каналов, Сетевые технологии
Иногда связь с интернетом критически важна, и даже несколько минут простоя могут дорого стоить, например, в банкоматах, сигнализациях, системах мониторинга и контроля доступа.
В таких системах обычно используется несколько подключений к интернету и автоматическое переключение между разными каналами в случае недоступности основного канала.
Мне надоело самостоятельно изобретать failover на USB модемах, и захотелось делегировать это отдельной умной железке. Я решил сравнить несколько промышленных роутеров, чтобы выяснить, оправдывают ли они свое название, и насколько они лучше моих костылей. В статье будут сравниваться роутеры производителей iRZ, Termit, Robustel.
Основные требования к роутерам:
- 2 SIM-карты и автоматическое переключение между операторами — роутер должен автоматически определять потерю связи на одном операторе и переключаться на резервного. Это особенно важно для подвижных систем, когда покрытие сотовой сети не идеально.
- Подключение по Ethernet — основная система должна видеть только шлюз по умолчанию, и не должна знать о модемной подсистеме на стороне роутера и переключениях каналов, поэтому никаких USB.
- Поддержка современных протоколов VPN: IKEv2 и OpenVPN — для удобства администрирования, и чтобы не зависеть от реальных IP-адресов, роутеры должны уметь VPN. При этом поддерживать не только устаревшие PPTP и L2TP, но и современные протоколы.
- (Опционально) поддержка GPS, наличие GPIO, serial интерфейсов RS-232/485 — эти функции не обязательны для наших задач, но мы рассмотрим их тоже, как бонус, который, возможно, будет кому-то полезен.
Наиболее распространенные ошибки и заблуждения при настройке DFSR
2018-09-23 в 12:20, admin, рубрики: best practice, configuration, data, dfs, DFSR, failover, files, mistakes, replication, Windows Server, данные, настройка, отказоустойчивость, ошибки, репликация, Серверная оптимизация, Серверное администрирование, системное администрирование, файлы, хранение данных[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]
Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.
Читать полностью »
Простой failover для вебсайта (мониторинг + динамический DNS)
2018-05-29 в 7:39, admin, рубрики: alert, alerting, DNS, Dynamic DNS, failover, okerr, даунтайм, Настройка Linux, оповещение, системное администрированиеВ этой статье я хочу показать, как легко и бесплатно можно сделать failover схему для веб-сайта (или любого другого интернет-сервиса) на комбинации мониторинга okerr и динамического DNS сервиса. То есть, в случае любых проблем с основным сайтом (начиная от проблемы с «PHP Error» на странице, и до нехватки места или просто подозрительно малом числе заказов в случае интернет-магазина), новые посетители будут направлены на второй (третий, и так далее) заведомо работающий сервер, или же на «Sorry» страничку, где им вежливо объяснят, что «есть проблема, мы уже в курсе и уже чиним, скоро починим» (а вы в этом случае на самом деле будете уже в курсе и сможете чинить).
Читать полностью »
Новое решение для поддержания доступности ИТ-инфраструктуры: Veeam Availability Orchestrator
2018-03-27 в 9:06, admin, рубрики: failover, Veeam, veeam backup and replication, Блог компании «Veeam Software», виртуализация, Восстановление данных, резервное копирование, репликацияПрактически каждый день мы узнаем о том, что в очередной компании произошел серьезный сбой в работе ИТ-инфраструктуры, который привел к серьезным финансовым и репутационным потерям. Системный сбой – первое, что приходит на ум, когда просчитываются возможные риски для работы ИТ-сервисов и организации в целом. Однако куда чаще имеют место другие причины: человеческий фактор, перебои в работе оборудования, отключение питания, вредоносное ПО, повреждение данных – все это может привести к полной остановке систем и приложений.
Вероятность же успешного аварийного переключения на резервную площадку – запланированного или срочного – будет невелика, если уделять недостаточно внимания процедуре и плану переключения, не обновлять его своевременно и не тестировать в нужные сроки. Неверно указанные зависимости машин и приложений, не задокументированные изменения, неправильные процессы, не проверенные на корректность работы приложения и сервисы, неверная последовательность запуска машин из реплик – это лишь некоторые из проблем, которые могут помешать успешному переключению как одного приложения, так и целого ЦОД.
Чтобы помочь организациям справиться с этими проблемами, компания Veeam недавно выпустила новое решение Veeam Availability Orchestrator для автоматизации управления работы с репликами ВМ при переключении на резервную площадку. (Первая версия решения поддерживает виртуальные машины на платформе VMware vSphere.) Подробнее о новинке читайте под катом.
Тренинг FastTrack. «Сетевые основы». «Продукция в сфере беспроводных локальных сетей». Эдди Мартин. Декабрь, 2012
2018-03-05 в 19:00, admin, рубрики: Advanced Location, aironet, BYOD, capwap, Cisco, Clean Air, Clean Air Express, Client Link, failover, MIMO, Mobility Services Engine, Prime Infrastructure, RFID, VMware, Блог компании ua-hosting.company, Сетевые технологии, хостингОколо года назад я заприметил интереснейшую и увлекательную серию лекций Эдди Мартина, который потрясающе доходчиво, благодаря своей истории и примерам из реальной жизни, а также колоссальному опыту в обучении, позволяет приобрести понимание довольно сложных технологий.
Мы продолжаем цикл из 18 статей на основе его лекций:
Тренинг FastTrack. «Сетевые основы». «Понимание архитектуры Cisco». Эдди Мартин. Декабрь, 2012
Тренинг FastTrack. «Сетевые основы». «Свитчи от Cisco». Эдди Мартин. Декабрь, 2012
И вот десятая из них.Читать полностью »
Докеризация высокодоступного Postgres кластера
2017-07-31 в 7:31, admin, рубрики: cluster, devops, docker, failover, postgresql, Replication and High Availability, Администрирование баз данных, Серверное администрирование, хранение данных
Пару месяцев назад мы переехали из Амазон на свои выделенные сервера(Hetzner), одна из причин тому была высокая стоимость RDS. Встала задача настроить и запустить master-slave кластер на выделенных серверах. После гугления и прочтения официальной документации, было принято решение собрать свое собственное решение высокодоступного асинхронного кластера Postgres.