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

Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных иили аппаратных решений, а также соглашений об уровне обслуживания (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 — это значит, что база данных хранит три копии каждого фрагмента данных на разных дисках, подключенных к трём разным компьютерам. Объяснение этому примерно такое: диски выходят из строя редко. Если диск вышел из строя, то есть время заменить его, и в это время у вас ещё две копии, с которых можно восстановить данные на новый диск. Риск выхода из строя второго диска, пока вы восстанавливаете первый, достаточно низок, а вероятность смерти всех трёх дисков одновременно настолько мала, что более вероятно погибнуть от попадания астероида.
Читать полностью »

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

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

Задача построить отказоустойчивый сервис, с хранением почты на серверах, с доступом по IMAP.
Кластер будет обслуживать компанию с порядком 60-ти филиалов, каждый из которых имеет свой домен 3-го уровня.

Главная задача сервиса, беспрерывный доступ к почте. Поэтому для хранилища будем использовать два географически разнесенных сервера, с синхронизацией почтовых каталогов.
Оба сервера будут активными, это значит что мы будем распределять нагрузку между нодами. Часть доменов будет обслуживать одна нода, часть доменов другая. В случае выхода из строя одной из нод, клиенты переключаются на другую.
В качестве фронтенда для распределения нагрузки маршрутизации клиентов будем использовать Nginx с модулем mail. Для приема почты, будем использовать два smtp сервера.

Схема:
Почтовый кластер своими руками - 1
Читать полностью »

Как мы отказоустойчивый кластер запускали - 1

Ошибки и сложности, с которыми мы столкнулись, запуская собственный кластер на базе VMmanager Cloud + Ceph. Читать полностью »

Сага о кластере. Все, что вы хотели знать про горизонтальное масштабирование в Postgres‘е - 1

Олег Бартунов (@zen), Александр Коротков (@smagen), Федор Сигаев

Илья Космодемьянский: Сейчас будет самая животрепещущая тема по PostgreSQL. Все годы, что мы занимаемся консалтингом, первое, что спрашивают люди: «Как сделать мультимастер-репликацию, как добиться волшебства?». Много профессиональных волшебников будут рассказывать о том, как это сейчас хорошо и здорово реализовано в PostgreSQL — ребята из Postgres Professional в рамках этого доклада расскажут про кластер все. Название соответствующее — «Сага» — что-то эпическое и монументальное. Сейчас ребята из Postgres Professional начнут свою сагу, и это будет интересно и хорошо.

Итак, Олег Бартунов, Александр Коротков и Федор Сигаев.
Читать полностью »

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

Что нам требуется?

image

  • Совместимый с оборудованием гипервизор
  • Кластер, с доступом к админке через веб-интерфейс
  • High Availability для виртуальных машин в кластере
  • Функция бэкапа и восстановления из коробки
  • Доступность для понимания и работы среднему администратору (вчерашнему школьнику-студенту).

Из Open-Source решений, наиболее простым в установке и настройке является Proxmox. Чтобы не оскорблять любителей oVirt и пр. (это не рекламная статья), оговорюсь, что изначальное требование к простоте установки и администрирования, на мой взгляд, у Proxmox все же более выражено. Также, повторюсь, у нас не ЦОД, а всего лишь кластер из 2-3-х нод для небольшой компании.
В качестве гипервизоров он использует KVM и LXC, соответственно держит KVM ОС (Linux, *BSD, Windows и другие) с минимальными потерями производительности и Linux без потерь.
Читать полностью »

CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb-s IB) - 1

Запустив наше облако, мы стали предоставлять сервис хранения, аналогичный S3 Амазона (с совместимым API, чтобы российские заказчики могли использовать стандартные клиенты для работы с S3, изменив только endpoint для подключения). Основная задача сервиса — хранение снапшотов виртуальных машин и различных файлов клиентов. Амазон был взят за образец, куда надо развиваться, и в начале 2014 года стало понятно, что имеющееся файловое хранилище устарело, заказчики требовали современных фичей, недоступных у нас и так нравящихся им у AWS. Но доработка существующего решения светила огромными трудозатратами, поэтому было принято решение построить новое S3-совместимое хранилище с нуля.

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

Это было чертовски долго, но всё прошло спокойно.Читать полностью »

Большинство организаций должны поддерживать непрерывность оказания услуг или доступа к корпоративным ресурсам в виртуальной среде. Поэтому администраторы ищут возможности легко и быстро решать проблемы с конфигурированием отказоустойчивых кластеров Hyper-V. Теперь такая конфигурация доступна не только большим компаниям, но даже малым и средним предприятиям, используя возможности недорогого продукта — 5nine Manager, который известный эксперт Trevor Pott назвал культовым для SMB в нашумевшей статье. Материал может быть интересен также администраторам vSphere, которые ищут альтернативу удобному, но дорогому решению VMware.
Читать полностью »

Этим материалом мы открываем цикл статей, посвященных технологии Shared DAS и ее использованию в ОС GNULinux.

В первой статье цикла описывается создание простейшего двух-узлового кластера высокой надежности и создание на его базе отказоустойчивой iSCSI-СХД с ZFS.

Настройка Linux кластера на Shared DAS и ZFS - 1
Читать полностью »


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