Камрады, надеюсь у вас нет больших планов на завтрашний вечер, потому что мы в DriverPack решили позвать сисадминов в ламповый паб и поделиться с вами радостью, связанной со скорым запуском нашей новой программы! Не спешите писать о том, как скучны, полны официоза, а главное бесполезны официальные мероприятия и презентации. Мы с командой также, как и вы не выносим корпоративного этикета и пафосно нудных презентаций по 10 часов. Поэтому и предлагаем встретиться именно в пабе — посидеть за кружечкой пива, отведать мясных бургеров, а за одно, во время дружеской беседы мы расскажем вам о новом продукте и послушаем ваши предложения по его развитию, а также ответим на все ваши вопросы. Я буду рад видеть вас на нашем мероприятии, которое пройдет уже завтра, 14 октября в одном из лучших московских пабов.

В начале этого года у наших облачных VDS появился публичный API. Он позволяет клиенту делать практически все те же действия с облачными виртуальными машинами и дисками, что и в панели: создавать, удалять диски и ВМ, изменять тарифы и размер диска и тп.

Вместе с появлением API появилась и идея на его основе реализовать систему мониторинга за ресурсами виртуальной машины (ВМ), работающую внутри машины, и автоматического увеличения/уменьшения необходимых ресурсов по необходимости — автоскейлинг (autoscaling, АS).

Уже несколько лет дата-центры многих компаний работают с вычислениями с ускорением на GPU. Наша компания сейчас изучает этот вопрос, поскольку такой тип вычислений становится все более востребованным. Так, вычисления с ускорением на GPU можно (и нужно) использовать для ускорения требовательных к ресурсам приложений, созданных для работы в таких сферах, как глубокое обучение, аналитика и проектирование. Этот метод используют в дата-центрах крупных компаний, в лабораториях научно-исследовательских организациях, на предприятиях.

Благодаря ускорению на GPU работают многие сервисы, обеспечивающие работу нейронных сетей или обрабатывающие данные, поступающие с умных автомобилей. Плюсом такого метода является то, что ресурсоемкая часть приложения, которая требует большой вычислительной мощности, обрабатывается на GPU, а все остальное выполняется на CPU. В последние несколько лет стали появляться комбинированные решения, на основе которых создаются высокоскоростные базы данных. Такие решения стоит использовать, например, для визуализации крупных массивов данных.

Если вашей организации нужно хранить и обрабатывать данные, то, независимо от их объёма, без облачной или локальной СУБД не обойтись. Сегодня мы поговорим о ведущих представителях рынка корпоративных баз данных, о тех разработках, на которые стоит обратить внимание в 2016-м году.

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

Уникальная по своим возможностям СУБД HPE Vertica легко справляется с обработкой данных не только бизнес-транзакций, но также межмашинного взаимодействия и Интернета вещей, позволяя управлять миром умных устройств в реальном времени.



Глобальная экономика входит в эпоху Интернета вещей и массового межмашинного взаимодействия. Это значит, отмечает Дэвид Джонс, старший вице-президент и генеральный директор бизнес-подразделения HPE по управлению информацией и ее организации, что уже скоро, примерно к 2020 году, по всему миру придется обрабатывать данные от 50 миллиардов смарт-устройств и одного триллиона приложений ― всего около 44 Збайт. Нет сомнений, что прежние СУБД, ориентированные на обработку транзакционных данных, циркулирующих в традиционных бизнес-приложениях, не справятся с такой нагрузкой. На смену им приходят СУБД нового поколения, изначально рассчитанные на работу с большими объемами и потоками данных. Одна из них ― HPE Vertica, способная анализировать в реальном времени огромные объемы информации, получаемой от всевозможных «генераторов» данных — не только традиционных транзакционных систем, но также датчиков и устройств Интернета вещей, систем межмашинного взаимодействия, АСУТП, веб-сайтов и прочих источников.

Вводная

Предположим, что мы настроили асинхронную репликацию на двух хостах с PostgreSQL. С какой проблемой могут столкнуться потенциальные пользователи? На мой взгляд самой очевидной является отставание реплики от ведущего мастера. Не страшно, если юзер (или его клиентское приложение) открыло BEGIN. В этот момент может разорваться соединение, и все незакомиченные изменения будут откачены.
Но возможна ситуация, когда ведущая СУБД выдаст пользователю COMMIT, резко упадёт, а на слейв не успеет дойти подтверждение транзакции. Тогда при восстановлении реплики эти данные попадут под ROLLBACK (так как на самом деле на ведомую ноду передаются не конечные данные, а вся последовательность действий), а пользователь будет ошибочно считать, что его данные были успешно сохранены.

Благодарность

Спасибо тебе, Хабр, за то, что ты есть и за те прекрасные часы которые я проводил в тебе! Спасибо, отважные хаброписатели, за статьи высокого качества, тонкого юмора и широкого кругозора. Только благодаря вам и Марь Ивановне (которая меня в первом классе научила читать) я добился серьёзных успехов в ИТ, а теперь хочу поделиться историей, когда нестандартное мышление помогло решить идиоматическую задачку от заказчика.

Вступление

Некоторое время назад я работал над проприетарным продуктом. Этот софт хранил свои данные во внешней СУБД. Первоначально работа осуществлялась с MS SQL, однако позже специально для пользователей «я только *nix-подобные системы ставлю» сделали совместимость с PostgreSQL. Тут взяли меня для решения задач класса «база данных упала — нужно восстановить по журналам транзакций».

В один прекрасный день команда поехала реализовывать очередной проект. Первоначально было оговорено, что на объекте уже есть два сервера Windows 2012, на которых будет развёрнут отказоустойчивый кластер MS SQL. Однако в последний момент у заказчика денег на инстансы не хватило, и мне было поручено ставить рostrge'совые БД, а так же как-то решить задачу отказоустойчивости. Спасибо сообществу разработчиков рostgres, которые скомпилировали установщик для Windows. Задачи:

При построении 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?

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