Привет, Хабровчане! Мы продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье речь пойдет об архитектуре данной системы. В прошлой статье мы разобрали нашу файловую систему ARDFS, а в данной статье пройдёмся по всем основным программным компонентам, из которых состоит vAIR, и по их задачам.
В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.
Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.
Читать полностью »
Привет! Я Артем Карамышев, руководитель команды системного администрирования Mail.Ru Cloud Solutions (MCS). За последний год у нас было много запусков новых продуктов. Мы хотели добиться, чтобы API-сервисы легко масштабировались, были отказоустойчивыми и готовыми к быстрому росту пользовательской нагрузки. Наша платформа реализована на OpenStack, и я хочу рассказать, какие проблемы отказоустойчивости компонентов нам пришлось закрыть, чтобы получить отказоустойчивую систему. Я думаю, это будет любопытно тем, кто тоже развивает продукты на OpenStack.
Общая отказоустойчивость платформы складывается из устойчивости её компонентов. Так что мы постепенно пройдём через все уровни, на которых мы обнаружили риски и закрыли их.
Видеоверсию этой истории, первоисточником которой стал доклад на конференции Uptime day 4, организованной ITSumma, можно посмотреть на YouTube-канале Uptime Community.
Читать полностью »
Борис Цирлин и Александр Кушнеров
30.10.2019
Для опытного разработчика схем не составляет большого труда узнать знакомую схему, в каком бы виде она не была нарисована. В этой статье мы покажем, что две транзисторные схемы из патентов являются вариантом асинхронного счётного триггера (АСТ). По сравнению со стандартной схемой, в схемах из патентов отсутствуют некоторые транзисторы. Это может рассматриваться как неисправность. Мы покажем, что, если такая же неисправность возникает в стандартной схеме, она продолжает работать правильно. АСТ, реализованный только на элементах ИЛИ-НЕ [1] или только на элементах И-НЕ известен как гарвардский триггер. Оба варианта схем показаны на Рис. 1, где g7 – это индикатор завершения переходных процессов. В дальнейшем мы его рассматривать не будем. На Рис. 1 показаны также графы сигнальных переходов (STG) [2] построенные в Workcraft [3].
Рис. 1. Асинхронный счётный триггер (АСТ) и его STG.
Обратим внимание, что в обоих вариантах АСТ есть три пары элементов (g1, g2), (g4, g5) и (g3, g6), которые имеют общий вход. Транзисторные схемы элементов 2И-НЕ и 2ИЛИ-НЕ показаны на Рис. 2. Трёхвходовые элементы устроены аналогично и содержат 6 транзисторов.
Рис. 2. Транзисторные схемы элементов 2И-НЕ и 2ИЛИ-НЕ.
Возьмём два элемента 2ИЛИ-НЕ и выберем у каждого вход, где p-MOS транзистор подключён к Uпит. Соединим эти входы вместе и подключим к земле (лог. 0). Оба транзистора откроются и напряжение на их стоках будет равным Uпит. Достаточно ли этого чтобы безопасно соединить стоки и заменить два транзистора на один, как показано на Рис. 3? Нет. Нужно проверить что произойдёт если на общий вход подать лог. 1. Выходы обоих элементов соединятся с землёй, и мы будем иметь мостиковую схему из четырёх p-MOS транзисторов. Для оставшихся двух входов имеем четыре комбинации 0 и 1. Легко показать, что ни в одной из них не возникает короткого замыкания между Uпит и землёй.
Рис. 3. Два элемента 2ИЛИ-НЕ, имеющие общий вход.
Что бы вы почувствовали, если в один прекрасный летний день дата-центр с вашим оборудованием стал бы выглядеть вот так?
Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». На фотографии один из четырёх дата-центров, где установлено оборудование, обслуживающее наш проект. За этими стенами находится около 4 тыс. единиц техники: серверы, система хранения данных, сетевое оборудование и т.д. — почти ⅓ всего нашего оборудования.
Большинство серверов — это Linux. Есть и несколько десятков серверов на Windows (MS SQL) — наше наследие, от которого мы на протяжении многих лет планомерно отказываемся.
Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.
Читать полностью »
Всем привет! Недавно состоялся открытый вебинар «Обеспечение отказоустойчивости хранилищ». На нём рассмотрели, какие проблемы возникают при проектировании архитектур, почему выход из строя серверов — это не оправдание для падения сервера и как сокращать время простоя до минимума. Вебинар провёл Иван Ремень, руководитель направления серверной разработки в «Ситимобил» и преподаватель курса «Архитектор высоких нагрузок».
Прим. перев.: Рады поделиться переводом замечательного материала от старшего технологического евангелиста из AWS — Adrian Hornsby. В простых словах он объясняет важность экспериментов, призванных смягчить последствия сбоев в ИТ-системах. Вы, наверное, уже слышали про Chaos Monkey (или даже применяли подобные решения)? На сегодняшний день подходы к созданию подобных инструментов и их реализация в более широком контексте осуществляются в рамках деятельности, которую называют chaos engineering. Подробнее о ней читайте в этой статье.
«Но за всей этой красотой скрывается хаос и безумие». — Tanner Walling
Пожарные. Эти высококвалифицированные специалисты каждый день рискуют жизнью, борясь с огнем. Знаете ли вы, что перед тем, как стать пожарным, необходимо провести в тренировках минимум 600 часов? И это только начало. Согласно отчетам, пожарные тренируются до 80% своего рабочего времени.
Летом традиционно снижается и покупательская активность, и интенсивность изменения инфраструктуры веб-проектов, говорит нам Капитан Очевидность. Просто потому что даже айтишники, случается, ходят в отпуск. И CТО тоже. Тем тяжелее тем, кто остаётся на посту, но сейчас не об этом: возможно, именно поэтому лето — лучший период для того, чтобы не торопясь обдумать существующую схему резервирования и составить план по её улучшению. И в этом вам будет полезен опыт Егора Андреева из AdminDivision, о котором он рассказал на конференции Uptime day.
При строительстве резервных площадок, при резервировании есть несколько ловушек, в которые можно попасть. А попадаться в них совершенно нельзя. И губит нас во всем этом, как и во многом другом, перфекционизм и… лень. Мы пытаемся сделать всё-всё-всё идеально, а идеально делать не нужно! Нужно делать только определённые вещи, но сделать их правильно, довести до конца, чтоб они нормально работали.
Failover — это не какая-то такая весёлая фановая штука «чтоб было»; это вещь, которая должна сделать ровно одно — уменьшить время простоя, чтобы сервис, компания, теряла меньше денег. И во всех методах резервирования я предлагаю думать в следующем контексте: где деньги?
У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.
Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.
Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.
Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с помощью стороннего плагина под названием pglogical.
В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.
TL;DR
В этой статье мы расскажем, как в сервисе 3CX PBX Express восстанавливать резервные копии существующих инсталляций АТС. Возможность восстановления конфигурации позволяет, например, переместить локальный сервер в облако, сменить хостинг или восстановить АТС в облаке после серьезного локального сбоя. Единственное требование при перемещении конфигурации — опция «Данные лицензии и FQDN имени» в резервной копии должна быть включена.
Перед перемещением вашей АТС в сервис PBX Express обратите внимание на следующее:Читать полностью »
