Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

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

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

Предисловие

OpenSIPS — это сигнальный SIP-коммутатор. Если вы хотите обрабатывать реально много SIP-звонков, то, скорее всего, мимо OpenSIPS не пройдете.
Система реально «mature», проверенная в бою и, со временем, обросшая множеством полезных (и не очень) модулей.

Вместе с этим, очевидно, что архитектура, заложеннная еще в 2001 году не отвечает современным требованиям.
Поэтому разработчики OpenSIPS заявили, что версия 2.0 будет вестись «с чистого листа».

Ниже приведен перевод документа OpenSIPS 2.0 Design. Интересно, что думает хабрасообщество по этому поводу.

Комментарии по существу я постараюсь передать разработчикам.

Зачем нужна новая архитектура

Текущая архитектура OpenSIPS (до версии 2.0) основана на концепциях, которым более 7 лет. В то время требования были простыми (простой stateless SIP-прокси, только UDP) и решения принимались в соответствии с этими требованиями. Но со всеми дополнениями, как в SIP так и функционале (таком как TCP/TLS, манипуляции в скрипте, поддержка диалогов, интеграция с внешними системами и т.д.), существующая архитектура больше не может удовлетворять требованиям и реальным сценариям использования.

Внимание! Внутри большой и структурированный текст с картинками.

Дорогие хабрачитатели, мы готовы представить вам видеозаписи всех докладов с конференции по высоким нагрузкам HPC, которая состоялась 9 августа в Москве.



Прямо сегодня (или в любое удобное для вас время) в программе:
Сергей Аверин XEK, Badoo (участвовал в создании таких проектов как Хабр, dirty, leprosorium, autokadabra, dribbler, trendclub и др.);
Юрий Насретдинов, Badoo;
Андрей Сумин AndrewSumin, Mail.ru Group (ранее Яндекс, HeadHunter);
Константин Осипов, Mail.Ru Group ( ранее Oracle, Sun, MySQL, Ringrows, Spylog, Interpro);
Даниил Павлючков, ITmozg.ru.

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

Аннотация

Даже если вы не используете VoIP в своей системе, или это не основное ваше направление, вас может заинтересовать сам метод мониторинга с помощью прогнозирования потому, что его можно успешно применять не только для транзитного VoIP. Метод мониторинга рассматривается на примере приложения к транзитному VoIP потому, что данная задача — яркий пример его использования. Стандартными методами задача не решается, а мониторинг методом прогнозирования реализуется сравнительно просто. То, что написано ниже, это не теоретические изыскания, это уже несколько месяцев успешно используется на практике.

Введение

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

Tarantool это замечательное высокопроизводительное no-Sql решение, разработка компании Mail.Ru. Исходники

Данное решение позволяет использовать как режим key/value, так и выборку множества записей в рекордсет по одному или нескольким критериям (полям поиска). Аналогов в рунете и не только, я пока не встречал. С натяжкой можно сравнить редис. Но в редисе — списковые данные и их нельзя выбирать по ключу. Судя до утверждениям разработчиков, скорость доступа по ключу превосходит memcache, при этом еще в бэдграунде осуществляется постоянное сохранение данных на диск. Но к сожалению, данная разработка имеет единственный perl клиент для доступа к данным, из-за чего не имеет такой популярности, как например у redis или memcache.

В doc/box-protocol источников есть описание Протокола, которое я в настоящее время переработал для написания клиента на Си и PHP. Изучив Протокол, вы можете реализоать нативный клиент на любимом Вам языке. Надеюсь, данная статья в этом Вам пригодится.

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

Хочу поделиться набором ссылок на нексолько полезных, интересных и, возможно, не самых известных материалов по JavaScript. Из них вы узнаете немного больше об истории появления языка, о его настоящем, тонкостях реализации в различных браузерах, и о будущем развития стандарта ECMAScript. О различных способах наследования в том числе об эмуляции «классического» ООП, множественном наследовании и миксинах. О функциональном стиле программирования в JavaScript: чистые функции, map, reduce, частичное применение и композиции функций. И, наконец, что если бы Хемингуэй писал на JavaScript?

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

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

Чтобы всё это работало почти «из коробки» и раза в полтора дешевле, мы сделали очень интересное SaaS-решение в своём облаке. Но для начала пройдёмся по основным моментам, облегчающим работу IT-отдела и экономящим средства.

Авторы позиционируют HyperDex как распределённое, отказоустойчивое, легко-маштабируемое, заточенное на очень быстрый поиск NoSQL key-value хранилище.

Главная фича — новый принцип хранения объектов в многомерном эвклидовом пространстве (рис. слева), используя гиперпространственное хэширование (hyperspace hashing) (на который, кстати, авторы сейчас получают патент), которое позволяет выполнять большинство типичных задач от 2 до 13 раз быстрее, чем в MongoDB, Redis, Cassandra.

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

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

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

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

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

Статья написана после прочтения статьи Копи деньги смолоду или пара утверждений, легко проверяемых в Excel.

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

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

Заголовок получился достаточно желтый, но он лучше всего передает суть поста: можно создать свое вычислительное облако, которое будет на порядок дешевле, чем предлагает Amazon EC2. Есть множество нюансов, из-за которых подобное “дешевое облако” может не подойди, но, на мой взгляд, для многих задач оно вполне подходит и справляется с ними отлично.

Далее я хочу рассказать о нашем опыте использования OpenStack, развернутого у Hetzner’a, и привести расчеты стоимости подобного облака.

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

Примечание: мы говорим только об автоматизированных БД, не включая те, которые требуют пользовательского администрирования

Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…

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

Сейчас на Хабре мало обзоров helpdesk-систем, правда, имеется сравнительный обзор SaaS-helpdesk (с хорошей ссылкой в комментарии от dude1phoenix), обзор OTMS-helpdesk и Request Tracker (как и OTRS написан на Perl).
Предлагаю вам поближе познакомиться с системой поддержки клиентов OTRS, с ее установкой на Debian и интеграцией с Active Directory предприятия.

Приветствую тебя, %habrauser%!

Предыстория:

В данный момент я работаю в небольшой конторе, которая занимается консультированием, аудитом и обслуживание в области IT. Хотя контора и небольшая, количество клиентов у нас росло быстрыми темпами, и без нормального хелпдеска обойтись было уже очень сложно. Рассмотрев приличный перечень продуктов, как платные так и бесплатные, наш выбор пал на продукт фирмы BestPractical, который называется весьма незамысловато Request Tracker.

В последнее время очень модными стали решения по построению облачных систем, облака строят все кому не лень. Для конечного пользователя все прозрачно: «Вот тебе точка входа, вот там твои ресурсы — используй!» И мало кто из них задумывается о том, как оно все устроено внутри. Да и не надо им знать, в сущности. Однако, людям, которые заняты как раз конфигурированием подобных систем, очень интересно, а как же это работает у других? И главное — на чем?

Постановка задачи

Описание проблемы

В работе активно используется Xen с HVM виртуализацией. Часто бывает нужно получить доступ к консоли виртуальных машин, причем в том числе и тем, у кого доступа на севера с Xenом нет. У Xenа для этого есть возможность создавать для каждой виртуальной машины VNC-консоль, но каждый раз подключаться через VNC вручную неудобно.

Задача

Сделать веб-страницу со списком запущенных виртуальных машин и внедренным в нее VNC-апплетом, который можно открыть по нажатию ссылки. По пути разобраться с тем, как можно работать с Xenом из Питона.

Что получилось

Список запущенных domU

Сама VNC-консоль

Волей случая, пришлось обновить домашний сервер, в новом сервере оказался процессор core 2 duo и прилично памяти (3 гигабайта). Т.к. обычно сервер использовался в качестве файлопомойки, раутера и музыкального сервера, решил его чем-нибудь занять, чтобы не простаивали ресурсы, благо их теперь достаточно много. Решил настроить довольно популярную в последнее время технологию виртуализации, чтобы было возможно проводит различные опыты с настройкой и собирать пакеты в различных дистрибутивах/системах.