При построении High Availability Configuration на базе оборудования RISC-платформ мы выбираем из весьма ограниченного набора кластерного ПО. В первую очередь это вендорские разработки – Oracle Solaris Cluster, PowerHA (IBM), Serviceguard (HP), а также Veritas Cluster Server. Последнее решение по факту является основным предлагаемым на данный момент вариантом построения кластерных конфигураций, причем для разных платформ – Oracle, IBM и т.д.

Однако мы решили не ограничиваться только этими разработками и поискать альтернативное кластерное решение для x86. Так был инициирован внутренний проект по тестированию кластерной конфигурации на базе ПО Pacemaker.

Всем доброго времени суток! Недавно жизнь подкинула автору увлекательную работу по развертыванию MongoDB кластера с настройкой репликации и шардирования, а также аутентификации c использованием x.509 сертификатов. В данной статье я в первую очередь хотел бы изложить свои мысли и поделиться полученными опытом. Так как некоторые вещи оказались не тривиальными и сделать их с первого раза не удавалось, то думаю мои пошаговые инструкции могут пригодиться для освещения вопроса тем кто только знакомится с шардированием данных и работой с MongoDB в целом.
Также я буду очень рад увидеть рекомендации по добавлению/изменению конфигурации кластера и просто вопросы или критику по самой статье или по сути вопроса.

На написание данной статьи меня сподвигло прочтение публикации «Как я спам слал» от пользователя Nike01. Руководство поставило передо мной похожую задачу по рассылке учетных данных пользователей средствами базы данных Oracle. В качестве SMTP relay должен был выступать сервер исходящих сообщений Яндекса, использующий SSL при авторизации.

В предыдущих публикациях мы уже затрагивали проблему обработки событий в реальном масштабе времени. Сегодня мы хотели бы вновь вернутся к этой теме и рассказать о новом и весьма интересном инструменте — потоковой СУБД PipelineDB.

Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай.
Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.

Вкратце:

1. cfdb — модуль развёртывания и автонастройки узлов и кластеров баз данных и доступа к ним с высокой доступностью и защитой от сбоев.
2. Как proof-of-concept поддерживаются MySQL и PostgreSQL на базе Percona Server/XtraDB Cluster и официальных сборок PostgreSQL+repmgr.
3. Изоляция ресурсов на базе cgroups, интеграция с настройками сетевого фильтра через модуль cfnetwork и строгий контроль доступа средствами СУБД.
4. Запись на один узел для минимизации конфликтов и распределение нагрузки для read-only доступа.
5. Автоматическая проверка здоровья кластера и фактической осуществимости доступа.
6. Ручное и автоматическое локальное резервное копирование, автоматизированное восстановление данных.
7. Поддержка автоматической миграции уже существующих баз данных

У меня возникла «бюджетная» идея использовать в качестве резервной СУБД (как временное решение на случай отказа) уже имеющийся в наличии NAS D-Link DNS-325. Организация небольшая + безотрывное производство + отсутствие дежурного специалиста, но это только для вступления.

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

Немного теории

ACARS (Aircraft Communications Addressing and Reporting System) — цифровая система связи, применяемая в авиации для передачи коротких, относительно простых сообщений между воздушным судном и наземными станциями, либо через прямую радиосвязь, либо через спутниковые системы.
AIRCOM – Сервер (шлюз) обмена сообщениями между различными сетями. Производитель — компания SITA. Связывает бортовое оборудование ACARS через сети ARINC с системой планирования полетов LIDO OC (Jeppesen Jet Planner или др.), электронной почтой, SITAtex, телефонией, файловым обменом и другими необходимыми информационными системами, используемые в авиакомпании.

Принцип работы AIRCOM Server

Информационная система SITA AIRCOM Server реализована на MS SQL и используется для обеспечения воздушных судов авиакомпании данными о маршруте, ветру на эшелонах, погоде и для обмена сообщениями «экипаж — ЦУП — экипаж». AIRCOM Server настроен на бортовое оборудование ACARC и функционирует совместно с ним. AIRCOM Server является критически важной информационной системой для обеспечения полетов.

Первая часть моих приключений с Tibero тут

Для тестирования совместимости Tibero c Oracle я решил проверить, будут ли работать на нем любимые мною PL/SQL библиотеки, а именно:
https://github.com/mortenbra/alexandria-plsql-utils/
Тестирование началось с JSON_UTIL_PKG. Очень полезная функция позволяющая быстро генерировать JSON-ответ.

Недавно в моей жизни закончился период поиска новой работы. На одном из собеседований этого периода я узнал, что в мире появилась новая СУБД, разработчики которой обещают вот-вот затмить собой Oracle всемогущий. Заманчивое обещание тут же породило у меня желание попробовать это чудо заморской техники. Речь шла о корейской СУБД Tibero.

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

Резервное копирование данных бизнес-приложений – тема древняя, как Кобол, и вечная, как процесс исправления ошибок на Windows. Истинные джедаи системного администрирования вооружаются с этой целью самопальными скриптами, представляющими обычно такое же удивительно постмодерновое сочетание новейших технологий и допотопного мышления, как световой меч из «Звёздных Войн». Офисные же самураи, в отличие от джедаев из серверной комнаты, идут к своему менеджеру-даймё и выпрашивают у него десяток-другой «коку» риса на покупку разрекламированной фирменной обработки для бэкапа данных. (Для тех, кто не в курсе: «обработкой» называется программа на внутреннем языке 1С, а «коку» — это такая мера объёма, которой самураи меряют свою зарплату.)
О проблеме создания резервных копий 1С задумался и я чуть больше года назад, впервые получив в списке своих служебных обязанностей коротенькую инструкцию – «обеспечить сохранность резервных данных предприятия в системе 1С с возможностью их эффективного восстановления». Увы мне – я не джедай-айтишник и не самурай-менеджер. По натуре своей я путешественник. И вот, воспользовавшись попутным гуглем и некоторыми благоприятными знамениями от бухгалтерии нашего института, я пустился в дальнее странствие, чтобы найти приличную утилиту для бэкапа данных 1С как в файловом, так и в SQL-режимах. Об открытых мною в этом странствии решениях и о связанных с ними различных удивительных приключениях и пойдёт речь в моём дальнейшем повествовании.

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

Какой же программный продукт выбрать для восстановления Aсtive Directory?

Для ответа на этот вопрос нужно сначала определиться со списком сценариев для восстановления.

Решил написать статью о том, как вытягивать данные из 1С путем SQL запросов. Все нижесказанное касается 1С версии 8.2, оно также должно работать и в 1С версии 8.1. Особое внимание уделено проблеме с извлечением заголовков перечислений.

Культурный способ

В идеале выборку данных из 1С должен делать 1С-программист. Хорошо, если он создаст обработку, которая выдаст данные в так называемую «буферную базу»: csv файлы, таблицы в SQL – что угодно. Проектировщик ХД и ETL должен брать данные из буфера.

В этом случае все работает предельно хорошо: зоны ответственности разделены, если найдена ошибка в данных отчета – ее вначале ищут в кубе, если в кубе все ОК – ищут в ХД, если в ХД все ОК – ищут в ETL, если в ETL все хорошо – значит пускай 1С-программист сам разбирается где у него ошибка в обработке, заполняющей «буферную БД».

Но не всегда такой способ доступен. Бывает, что 1С-специалиста либо вообще нет, либо слишком занят, либо мощностей железа не хватает, чтобы «выталкивать» данные из 1С с помощью обработки. И остается одно – делать извлечение данных с помощью SQL запросов.

Не очень культурный способ

Вот это собственно и есть этот способ – «сделать SQL запрос на 1С-базу». Главная задача – корректно написать сами запросы. Я думаю, ни для кого не есть секретом, что в 1С структура данных «хитрая», и что поля и таблицы имеют замысловатые названия. Задача проектировщика ETL – вытянуть данные из этой структуры.

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

HADR инструмент DB2, реализующий зеркалирование баз данных. ACR механизм в Websphere позволяющий в случае падения базы, автоматически переключать клиентов на резервный сервер. Ниже расскажу как настраивал обе эти штуки 8-)

Сколько раз вы испытывали проблемы с производительностью SQL Server'а и решали, куда именно смотреть?

Одна из самых редко используемых методологий устранения проблем с производительностью SQL Server'а называется «Ожидания и очереди» (также известная как «статистика ожиданий»). Основная предпосылка методологии состоит в том, что SQL Server постоянно отслеживает, какие потоки выполнения должны ждать. Вы можете запросить у SQL Server'а эту информацию для того чтобы сократить перечень возможных причин проблем с производительностью. «Ожидания» — это то, что отслеживает SQL Server. «Очереди» — это ресурсы, доступ к которым ожидают потоки. Система обычно фиксирует огромное количество ожиданий, и все они означают ожидание доступа к различным ресурсам. Для примера, ожидание PAGEIOLATCH_EX означает, что поток ожидает чтения страницы данных с диска в буферный пул. Ожидание LCK_M_X означает, что поток ожидает возможности наложить эксклюзивную блокировку на что-то.

Отличная новость состоит в том, что SQL Server знает, в чем именно заключаются проблемы с производительностью, и все что вам нужно — это спросить у него… и потом правильно интерпретировать то, что он скажет, что может быть немного сложнее.

Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:

• купить еще один такой же винчестер и объединить их в raid-0.
• купить небольшой SSD и организовать на нем быстрый кэш:
  
  • dm-cache. Был добавлен в ядро 3.9, ставится просто.
  • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
  • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.

Взвесив плюсы и минусы, а так же спросив отзывы знакомых, я решил остановиться на bcache. О нем и расскажу подробнее.

Очень многие разработчики считают что лучший интерфейс для работы с базами данных — текстовый интерфейс консольного. Я лично еще не достиг подобного просветления, поэтому больше доверяю GUI-инструментам. Хорошо, если у СУБД как у Postgres есть своя, утилита для работы с БД, а что делать если нет? Или если надо работать с различными базами данных одновременно? Под Windows альтернативных клиентов к различным СУБД — море разливанное. С другими ОС (я в данный момент работаю в OS X) все не так радужно, хотя есть программы разной степени пригодности и удобства. Раньше я использовал Navicat, но недавно нашел еще одно интересное решение, о котором и хочу рассказать: Valentina Studio.

Сразу скажу — я общался с разработчиками, и мне очень импонирует их концепция, то что они делают и как, поэтому я решил просто написать обзор о хорошем инструменте, о котором мало кто знает, поскольку публичный релиз программы состоялся очень недавно. До этого она долгое время разрабатывалась для Valentina DB и только в феврале вышла версия с поддержкой известных популярных баз данных. При этом разработчики приняли достаточно разумное решение — базовая версия совершенно бесплатна, а деньги берут только за несколько мощных «особо профессиональных» функций без которых чаще всего можно обойтись.

За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.