Мы собрали форк MySQL от Facebook с движком RocksDB вместо InnoDB и потестировали его с реальными приложениями: Drupal, Wordpress, Redmine.

Это офигенная штука. При низкой нагрузке выигрыш маленький, десятки процентов. Зато при высокой нагрузке выигрыш в разы. Когда RocksDB добавят в стабильный релиз в MariaDB, я уверен, что в течение полугода половина народа перейдет с InnoDB на RocksDB. Особенно, небольшие сайты на cloud/VPS и выделенных серверах.

Что такого хорошего в MyRocks? Линейная запись вместо случайной и снижение числа дисковых операций вообще. То есть транзакции базы данных порождают меньше дисковых операций, меньше занимают очередь диска, и пишутся намного быстрее.

Я собрал в статью результаты тестирования реальных сценариев Redmine, добавил анализ результатов и выводы. Redmine на MySQL с RocksDB оказался быстрее, чем с InnoDB — от 20% при минимальной нагрузке до 3 раз при максимальной. Позже подготовлю материалы по Drupal и другим PHP-приложениям.

Вы сможете проверить работу MyRocks и самостоятельно — в конце статьи есть ссылки на инсталляторы и виртуальные машины с LAMP/LEMP/Ruby стеками, собранные с MyRocks вместо MySQL.

Как было понятно из прошлой статьи “Четыре порока обслуживания”, мы активно внедряем ITSM подходы в нашей компании. Сегодня хотелось бы поговорить о том, с чего обычно начинается внедрение ITSM в компании — о каталоге услуг.

Выделение услуг оказалось не совсем простой задачей и мы столкнулись с массой сложностей:

• Можно принимать за ИТ-услугу программный комплекс или нет?
• Как выделить единого ответственного, если услуга составная и поддерживается двумя программными комплексами?
• Как определять по какой услуге зарегистрировать инцидент, если рухнула ИТ-инфраструктура в целом и почти все услуги не предоставляются.

Вот каких принципов мы придерживаемся при выделении любой услуги:

В последнее время я как-то подозрительно часто наблюдаю примитивнейшие однотипные и довольно легко решаемые проблемы на самых разных web-проектах. Разные базы, разные языки, разные сферы деятельности и схемы монетизации. Всех их объединяет одно — лозунг «бизнес не дает переписать». Продолжающийся или только-только оконченный этап рапид-разработки растущего и агрессивно отжимающего у конкурентов долю рынка проекта родил огромную кучу т.н. «говнокода». Сомнительные архитектурные решения либо уже приносят кучу проблем, либо обещают их в будущем, но работают. Поток новых требований не дает времени навести порядок даже в инфраструктуре, не говоря уже о коде. Если вам такая ситуация знакома — добро пожаловать под кат поностальгировать, поучиться чему-то новому и/или поучить нас. Кому поржать, а кому и поплакать.

«Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.

Привет! В этой статье я хочу рассказать о проекте Akumuli, специализированной базе данных для сбора и хранения временных рядов. Я работаю над проектом уже больше четырех лет и достиг высокой стабильности, надежности, и возможно изобрел кое-что новое в этой области.

Временной ряд это упорядоченная во времени последовательность измерений, если говорить максимально просто, это то что можно нарисовать на графике. Временные ряды естественным образом возникают во многих приложениях, начиная с финансов и заканчивая анализом ДНК. Наиболее широкое применение базы данных временных рядов находят в мониторинге инфраструктуры. Там же часто наблюдаются самые серьезные нагрузки.

“Мне не нужна TSDB, у меня уже есть Х”

Х может быть чем угодно, начиная с SQL базы данных и заканчивая плоскими файлами. На самом деле все это действительно можно использовать для хранения временных рядов, с одной оговоркой — у вас мало данных. Если вы делаете 10 000 вставок в свою SQL базу данных — все будет хорошо какое-то время, потом таблица вырастет в размерах настолько, что время выполнения операций вставки увеличится.

Если ваша работа требует держать множество SSH-сессий к разным серверам, вы наверняка знаете, как они легко ломаются при переключении на другой Wi-Fi или при временной потере интернета. Но что, если я скажу вам, что все эти проблемы давно решены и можно забыть про сломанные сессии и постоянные переподключения?

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

Если использовать БД временных рядов (timeseries db, wiki) как основное хранилище для сайта со статистикой, то вместо решения задачи можно получить много головной боли. Я работаю над проектом, где используется такая база, и иногда InfluxDB, о которой пойдет речь, преподносила вообще неожиданные сюрпризы.

Хабр, привет!

Меня зовут Марина Могилко, я кофаундер онлайн-платформы LinguaTrip.com.

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

Все советы рассчитаны на тех, кто уже обладает минимальным уровнем английского — учил его в школе или на курсах. Но заговорить через месяц смогут и те, кто только знакомится с языком, правда, им будет труднее. В статье не будет рекомендаций типа «учите язык вместе с носителем языка» или «погрузитесь в языковую среду». Это действенные методы, но они не всегда подходят.

Итак, начинаем! Осторожно: под катом мини-словарик на все случаи жизни.

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

Во всем спектре существующих IT-услуг техническая поддержка всегда была солью земли, альфой и омегой оказания услуг, связанных с компьютерами. Поддержка существует как для программных продуктов, так и для инфраструктуры. И цель везде у нее примерно одинакова – помогать пользователю и решать его проблемы, быть связующим звеном между ним и обслуживаемой инфраструктурой. И если личные и профессиональные качества сотрудников техподдержки остаются вне пределов сферы моего влияния (я же админ, а не психолог), то создание комфортной экосистемы для работы – одна из прямых моих профессиональных обязанностей. Техподдержка поддерживает пользователей, а я – техподдержку.

В ту же реку

Относительно недавно я написал себе шпаргалку по настройке FreeSWITCH. Описанный там процесс настройки привел к работоспособной в тестовых условиях конфигурации. Тест был необходим для составления предварительного представления о том, с чем придется иметь дело после переезда организации и запуске телефонии в продакшн. Однако, когда переезд состоялся и началось подключение в рабочем режиме, то первое же включение показало неработоспособность конфигурации: перестали ходить внутренние вызовы.

1 ноября 2018 года Московская Область без объявления войны (объявленной парой лет ранее), ввела финансовые санкции. Против собственников территорий, предоставляющих плацдарм для распространения борщевика Сосновского. Ура!

Мне, правда, интересно, кто будет платить за титаническую плантацию борщевика между Шереметьево и ниткой Аэроэкспресса. Плантацию, встречающую гостей и жителей Москву сразу по прилёту в белокаменную. Там растут просто миллионы штрафа.

Что же такое борщевик Сосновского и почему с ним надо бороться. Как это делать. Как это делать не нужно. А так же научные и псевдонаучные факты в нескучно-популярном изложении.

Статья отражает личный опыт автора – заядлого программиста микроконтроллеров, которому после многолетнего опыта микроконтроллерной разработки на языке С (и немного на С++) довелось участвовать в крупном Java-проекте по разработке ПО для ТВ-приставок под управлением Android. В ходе этого проекта удалось собрать заметки об интересных различиях языков Java и C/C++, оценить разные подходы к написанию программ. Статья не претендует на роль справочника, в ней не рассматривается эффективность и производительность Java-программ. Это скорее сборник личных наблюдений. Если не указано иное, то речь идет о версии Java SE 7.

Видеонаблюдение стало неотъемлемой частью нашей жизни. В течение дня мы попадаем в объективы десятков камер видеонаблюдения и уже не замечаем этого.

Спектр решений для видеонаблюдения широк, и включает как простые регистраторы, так и решения на базе серверов, с использованием профессионального ПО. Причём каждое из решений занимает свою нишу и решает задачи разного уровня сложности.

Простые регистраторы малоинтересны для подробного изучения, т.к. имеют базовые возможности: запись по движению и просмотр архива. Профессиональные решения видеонаблюдения имеют более богатый функционал: различные детекторы, счётчики, аналитические модули и интеллектуальный поиск в архиве. Одним из ведущих отечественных разработчиков в этой области является компания Macroscop.

Из-за растущего спроса на решения на базе программного обеспечения Macroscop, для удобства подбора конфигурации, мы открыли новую модель сервера для видеонаблюдения STSS Flagman VX123M.4-012LH. В конфигураторе сервера можно выбрать все необходимые лицензии.

Для понимания возможностей Macroscop, определения уровня нагрузки этого ПО на аппаратную часть решения, было проведено тестирование. Особый интерес у меня вызывали интеллектуальный поиск в архиве и аналитика.

Несколько лет назад, при выборе первого хранилища для дома, я смотрел в сторону «коробочных решений» по причине не особой осведомлённости в построении системы хранения на базе открытого ПО и обычного ПК. В тот раз выбор пал на 2-дисковую NAS — Shuttle KD20. Хранилище было компактным и тихим. RAID1 обеспечивал необходимую надёжность, а потребности в высокой производительности и расширенном функционале на тот момент не было. Этот NAS проработал почти 4 года, пока в один прекрасный момент не накрылась линия питания вентилятора. Диски раскалились до 60 градусов и чудом выжили. Я запаял вентилятор напрямую к материнке, но стал подбирать вариант на замену. В качестве второй NAS я выбрал 4-дисковую Synology. Задачи оставались те же, поэтому в функционал DiskStation Manager (DSM) я особо не вникал. Это продолжалось до тех пор, пока я не решил установить домашнее видеонаблюдение на несколько каналов. Не смотря на то, что Synology имеет собственный сервис видеонаблюдения, я остановился на Macroscop — была потребность в расширенном функционале и серьёзной аналитике. На своё счастье, я обнаружил в DSM новый пакет Virtual Machine Manager — гипервизор, с помощью которого я создал виртуальную машину и установил на неё Windows и Macroscop. На запись система работала нормально, встроенный Pentium 1,6 ГГц с трудом, но успевал отрабатывать задачи СХД и виртуальной машины. Но как только активировалась какая-либо аналитика — сервис отваливался по перегрузке процессора. В результате, я был вынужден начать поиски отдельного бюджетного Windows-девайcа с адекватной производительностью для реализации сервера видеонаблюдения, так как Synology необходимого уровня стоит недёшево. В тот самый момент я в очередной раз наткнулся в сети на статьи, посвящённые установке DSM на обычное железо и мой проект XPenology начался…

Введение

Пришла пора покупать СХД. Какую взять, кого слушать? Вендор А рассказывает про вендора B, а еще есть интегратор C, который рассказывает обратное и советует вендора D. В такой ситуации и у опытного архитектора по системам хранения голова пойдет кругом, особенно со всеми новыми вендорами и модными сегодня SDS и гиперконвергенцией.

Итак, как же во всем этом разобраться и не оказаться в дураках? Мы (AntonVirtual Антон Жбанков и korp Евгений Елизаров) попробуем об этом рассказать русским языком по белому.
Статья во многом перекликается, и фактически является расширением “Дизайна виртуализованного ЦОД” в плане выбора систем хранения данных и обзора технологий систем хранения. Мы кратко рассмотрим общую теорию, но рекомендуем ознакомиться и с указанной статьей.

Зачем

Часто можно наблюдать ситуацию как приходит новый человек на форум или в специализированный чатик, как например Storage Discussions и задает вопрос: “вот мне предлагают два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, что посоветуете”?

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

Если вы когда-нибудь работали с такими низкоуровневыми языками, как С или С++, то наверняка слышали про указатели. Они позволяют сильно повышать эффективность разных кусков кода. Но также они могут запутывать новичков — и даже опытных разработчиков — и приводить к багам управления памятью. А есть ли указатели в Python, можно их как-то эмулировать?

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

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

Вторая часть

Итак, продолжу свои редкие статьи на тему «как не платить HP/EMC/IBM многие кило-(или даже мега-) доллары и собрать своё хранилище не хуже». Прошлый цикл я до победного конца не довёл, но 90% мыслей всё же оформил в текст.

Нашей сегодняшней целью будет отказоустойчивое «All-Flash» (то есть — только из SSD, без жестких дисков, хотя это и не принципиально) хранилище для нужд кластера vSphere, в несколько раз дешевле брендовых аналогов и с очень неплохой производительностью. Подключаться к нему мы будем по Fibre Channel, но никто не мешает сделать iSCSI, FCoE или даже, о ужас, Infiniband.

Syncro

Как ясно из названия, основой всей этой богодельни станет достаточно уникальный на рынке продукт под названием Syncro CS от компании LSI (ныне Avago).

Что же оно такое есть и чем примечательно?

По сути, это комплект из двух обычных контроллеров LSI 9286-8e (либо 9271-8i, если нужны внутренние порты) и двух суперконденсаторов для сохранения кеш-памяти на флешку контроллера в случае потери питания. Стоимость комплекта при этом в несколько раз выше цены аналогичного комплекта без HA-функционала. Но, если сравнивать с решениями на базе DRBD, то эта разница с лихвой компенсируется отсутствием необходимости иметь двойной набор накопителей.

Но самое интересное кроется в прошивке. Благодаря ей, эти контроллеры, будучи подключенными к одной SAS-сети (например, дисковой корзине с экспандерами) устанавливают через неё связь друг с другом и работают в режиме отказоустойчивого кластера.

Для нас это интересно вот чем:

• Возможность создавать RAID-массивы, доступные сразу на двух серверах
  
• Отказоустойчивость на уровне контроллеров: при смерти одного из них (или целиком сервера) второй продолжит работать и обслуживать I/O

Часть первая

Продолжаем

Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.

В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:

# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.

После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:

# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2

Pacemaker

Итак, менеджер кластера.

Часть вторая

Прелюдия

Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.

Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам.

Вводные

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

В качестве гипервизора был выбран vSphere, как наиболее устоявшийся и законченый продукт, а в качестве протокола — iSCSI, как не требующий дополнительных финансовых вливаний в виде коммутаторов FC или FCoE. С опенсурсными SAS таргетами довольно туго, если не сказать хуже, так что этот вариант тоже был отвергнут.

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

В качестве софта было выбрано:

• Debian Wheezy + LTS ядро 3.10
• iSCSI-таргет SCST
• DRBD для репликации
• Pacemaker для управления ресурсами кластера и мониторинга
• Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)

В итоге, в недолгих муках была рождена такая несложная схема:

Доброго времени суток, уважаемое сообщество!

В этой статье я хотел бы поделится опытом создания дискового хранилища, который вылился во множество экспериментов, проб, ошибок, находок, приправленных горькими разочарованиями. И, наконец, завершился в неком интересном, относительно бюджетном и быстром хранилище.

Если у вас есть подобная задача или вас просто заинтересовал заголовок, то добро пожаловать под хабракат.

Разбивая крупные числа на мелкие, исследователи превысили фундаментальное математическое ограничение скорости

Четыре тысячи лет назад жители Вавилонии изобрели умножение. А в марте этого года математики усовершенствовали его.

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

«Все думают, что метод умножения, который они учили в школе, наилучший, но на самом деле в этой области идут активные исследования», — говорит Йорис ван дер Хувен, математик из Французского национального центра научных исследований, один из соавторов работы.