§ LVM-based sandbox.

Еще одна причина почему я люблю LVM.

Еще один лирический пост, в котором я снова рассказываю о том что мне нравится и почему. На этот раз речь пойдет об LVM (Logical Volume Manager). Если вкратце, то это менеджер управления логическими дисками который позволяет абстрагироваться от уровня физических накопителей и оперировать разделами на логическом, более гибком уровне, то это инструмент позволяющий гибко управлять дисковыми разделами. Гибкость заключается в том что LVM позволяет объединять целые диски в логические группы и внутри этих групп создавать дисковые разделы. Управлять этими разделами очень удобно, можно на лету менять размеры тома, распределять том на несколько физических дисков, делать зеркалирование, создавать снимки и многое другое. Снимки, или так называемые снапшоты, о них я и расскажу сегодня.

§ Linux kernel modules.

Add kernel functionality without reboot.

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

§ Moxi: Memcache/Membase proxy.

Moxi: is a proxy for memcached traffic

Продолжаем разговор про прокси для memcached. На этот раз речь пойдет про Moxi. Это прокси для Memcached/Couchbase (ранее Membase).  Здесь следует сказать что, в первую очередь moxi предназначен для совместного использования с Couchbase. Но тем не менее его можно использовать и в качестве прокси для memcache-клиентов.

§ Twemproxy: Memcached/Redis proxy.

Twemproxy (Nutcracker) - Memcached/Redis proxy.

Давно ничего не писал, времени совсем нет... - Держись студент, сессия!!! Сказал черт размахивая ведром гвоздей. Ходят слухи что смена деятельности только полезна. Но отбросим лирику и перейдем к делу...

Совсем недавно озадачился вопросом, а как масштабируется memcached? А никак)))  Но что делать если одного сервера недостаточно. Сходу подумалось о repcached, но там репликация, да и больше чем на 2 узла не разгонишься. Поиски привели к трем инструментам: memagent, moxi и twemproxy. Все эти инструменты представляют собой прокси с более-менее разным набором функций и качеств. Потестировав все три, остановился на twemproxy. О нем и пойдет речь.

PERF_EVENTS vulnerability defend

Локальное решение проблемы c PERF_EVENTS

недавно нашумевшая уязвимость CVE-2013-2094 связанная с PERF_EVENTS лечится установкой sysctl переменных kernel.perf_event_paranoid и kernel.perf_event_max_sample_rate

# sysctl -w kernel.perf_event_paranoid=2 
# sysctl -w kernel.perf_event_max_sample_rate=-1

§ PostgreSQL backup and recovery.

PostgreSQL: резервное копирование с минимальным временем восстановления

Предположим что у нас есть кластер postgresql работающий в режиме потоковой репликации. Есть master-сервер и горячий hot-standby готовый в любой момент стать полноценным мастером. Таким образом у нас реализована отказоустойчивая связка, в которой в случае выхода из строя мастера, горячий hot-stnadby заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. И стало все хорошо.

Известно что природа потоковой репликации устроена так, что изменения прошедшие в мастере, должны оказаться на подчиненном узле как можно быстрее. Выходит что, подчиненный узел представляет собой (почти полную) копию мастера. Это очень хорошо в случае немедленного восстановления на момент предшествующий сбою.  Однако, возможны ситуации когда вполне легитимные изменения были сделаны на стороне приложения и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных ничего фатального не произошло, а с точки зрения бизнеса - произошла катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная... 

§ EnhanceIO: How-to setup.

EnhanceIO Howto.

Продолжение истории о EnchanceIO. На этот раз только практика и совсем чуть-чуть теории.