highload, 2/2
В этой части отчета о конференции highload-2007 я напишу о втором дне мероприятия, а в конце попробую подвести итоги. Отчёт о первом дне, если вы вдруг его не читали, здесь (Зайцев, Демкин, Таксиков, Аксенов, Орлов, Хайруллин, Крюков, Андрюнин) .
Тюнинг операционных систем / Дмитрий Лоханский
Очень тяжело доклад на такую необъятную тему втиснуть в 45 минут, поэтому Дмитрий поступил разумно: прямо сразу начал рассказывать о параметрах настройки, которые могут значительно повлиять на производительность системы в целом, для трех принципиально важных "физических" компонента системы - памяти, диска и сети. Из-за того, что времени было совсем немного, докладу несколько не хватало академичности - всё-таки больше это было похоже на некоторый перечень имен констант, которые можно как-нибудь покрутить, чтобы что-нибудь поменялось. В материалах текста чуть больше, но зато куда-то пропали некоторые конфигурационные параметры, которые были на слайдах. Некоторые важные аспекты не были затронуты, например ничего не было сказано ни о планировщике, ни о context switches (важные темы для тюнинга веб-тачек), но что ещё важнее - как мониторить систему через всякие *stat. Вряд ли стоит в этом упрекать докладчика, нехватка времени - дело сёрьезное. В-общем если сложить это всё вместе, то получается вполне себе картина, и если, например, новичку с ней разобраться, думаю этого вполне будет достаточно чтобы задать дальнейший вектор для. Если автор сможет собрать воедино части из презентации и из материалов и добавит описание основных инструментов администратора, при помощи которых можно вообще посмотреть, что же у нас в системе происходит - по-моему это будет очень неплохой учебный курс, который нужен многим администраторам и в особенности разработчикам (которые к сожалению в массе своей вообще не представляют, как оно всё работает внутри). Поэтому один из первых вопросов докладчику был о том, а можно ли всё это дело где-нибудь прочитать. На что докладчик ответил что-то в духе RTFM, и хотя по большей части это верно, я всё-таки хочу заметить, что есть очень неплохая книжка Мусумеси и Лукидеса, которую было бы не грех в таких случаях рекомендовать - Настройка производительности UNIX-систем. Там правда больше про Sparc/Solaris, но есть кое-что и про Linux (и увы - ничего о FreeBSD), но зато она очень помогает понять, как там всё внутри живет, как это хозяйство мониторить и тюнить.
Сетевая многозадачность: событийные машины / Павел Кудинов
Павел не раз открыто говорил: я, ребята, поисковый спамер. А спамеры - они хитрые. И задачи у них есть ой какие интересные. Доклад произвел на меня двойственное впечатление. С одной стороны тема отличная, и содержание в-общем хорошее, рассказал всё бойко, начал издалека, о prefork/worker, тредах и мультиплексировании (это и есть снова событийных машины, если кто не понял - короче всё, что делает select, poll и прочие kqueue/epoll), затем рассказал про libevent и POE (libevent - всем известная билиотека на Си для обработки сетевых соединений, а POE - фреймворк на Perl, ипользуется для написания разного рода сетевых сервисов (раньше я тут написал что POE поверх libevent - это неверно, спасибо quappa), очень мощная и удобная штука, кстати). Даже успел рассказать немного об архитектуре прикладных сервисов с использованием этого добра и их кластеризации (спамерское, разумеется - сборщик ответов от каких-то там сервисов). С другой стороны, на системном уровне как-то всё было очень бегло, а местами по-моему просто неверно. К сожалению, я не могу вспомнить конкретно, где были косяки, потому что в материалах ни схем из презентации, ни некоторых разделов просто не было, лишь помню, что меня например насторожили фразы о модели обработки сетевых соединений апачём, где мастер якобы там что-то принимал и передавал воркеру, ну или что-то в этом духе. Что касается практических примеров, то с аналитической и ахитектурной точки зрения всё это хозяйство конечно представляло интерес для слушателей, но паталогическое желание докладчика называть элементарнейшие вещи сложными умными словами заставляло меня буквально продираться сквозь этот поток к совершенно простым и понятным вещам (попробуйте прочитать текст презентации из материалов конференции, и вы поймёте, о чём я). Короче. И тема хорошая, и содержание хорошее, но над подачей надо бы поработать. В первую очередь - быть проще. Никакого rocket science тут нету. Чуть больше времени уделить обзору моделей обработки сетевых соединений - снова будет хороший учебный доклад.
Кластерные параллельные вычисления / Владислав Шабанов (РБК-Медиа Мир/Вертикальный поиск)
Владислав в прошлом был одним из ведущих разработчиков Рамблера. Насколько я понимаю, с недавних пор (вернее, с тех пор, как с Рамблером в очередной раз случились разного рода перемены) - руководитель группы "Вертикальный поиск", каким-то загадочным образом сотрудничающей с РБК (похоже, скоро поиск будет у всей большой четвёрки). Доклад был о том, как на основе нескольких базовых примитивов ("реляционные" таблицы) и операций над ними (слияние, расщепление, фильтрация, сортировка и проч.) реализовать паралельные вычисления для тех задач, когда для расчетов приходится использовать кучу машин, и на каждой машине данных столько, что уместить их в память обычно не представляется возможным. Всё вместе это называется чудесным термином S3M2J, что соотвествует базовым операциям над таблицами: sort, split, scatter, merge, map, join. Например, задача распределенного сохранения объектов решается примерно по следующей программе: взяли порцию данных, порезали (split), отсортировали (sort), отправили на сервера в кластере (scatter), и там соединили с тем, что лежало раньше (join). Все примитивы реализуются библиотекой на С++, есть XS-интерфейс к Perl. На основе данного фреймворка реализован поисковый движок и статистика Рамблера, а также ряд других задач. Система "полна" в математическом смысле, то есть в рамках этого подхода могут быть решены практически любые задачи. Всё это очень напоминает и MapReduce, и Hadoop; хорошо масштабируется и оптимально использует диски (почти всё строго сортировано, последовательные чтение-запись), но похоже, что пока не начнешь с этим работать вплотную, не прочуствуешь. На мой вопрос о том, будет ли пущен этот фреймворк в open source автор ответил что-то в духе, мол, хрен его знает, массовому пользователю это не надо - но будет пущено, если будет спрос со стороны других открытых исследовательских проектов. Так что если вы представляете такой проект - можете попробовать получить исходники. В общем, такой исключительно концептуальный доклад, весьма интересно, но поскольку нельзя ничего скачать-потрогать и посмотреть конкретные примеры - лично у меня осталось некоторое недопонимание.
Использование nginx как сервера-сборщика / Андрей Баранов, Денис Ерыгин (Mail.RU)
Когда я прочитал название этого доклада, я задумался: что же собирает nginx? мусор? бутылки? подати? Оказывается, собирает он HTML. Ребята взяли ctpp - шаблонизатор на C++, который давно использовался в Мейле - и вкрутили это хозяйство модулем в nginx. Предыстория вопроса простая: портальные страницы состоят из кучи разны кусков, которые обычно отвечают совершенно разным приложениям. Nginx очень быстро умеет SSI, и даже умеет SSI с удаленного хоста, но до полноценного шаблонизатора ему далеко (здесь раньше я ошибся, написав, будто nginx не умеет SSI удаленно, и меня поправили в каментах __si__ и proforg). Поэтому архитектура следующая: с удаленного хоста взяли данные (используется формат JSON, как наиболее простой для парсинга), а nginx просто "накладывает" на это дело шаблонное преобразование. С одной стороны, шаг не очень логичный: nginx всё-таки быстрый веб-сервер, и нефиг на него накладывать какую-то логику, плюс делать самостоятельно запросы на внешние сервера (точнее, делать-то можно, только это надо делать крайне аккуратно, потому что малейший косяк затормозит всю систему к чертовой матери). С другой стороны, обычно на фронтендах, если на них ничего не крутится, простаивает проц, и если перенести нагрузку по оборачиванию данных в шаблоны с бэк-ендов, то в-общем можно перераспределить нагрузку и более грамотно использовать ресурсы системы. На мой вопрос о целесообразности данного решения ответили "у нас всё круто", но я конечно ожидал, что докладчики смогут предоставить данные о том, каким макаром в их конфигурации при переносе "сборки" страниц на фронтенды понизилась нагрузка на бэкенды, и насколько она подросла на фронтендах. Собираются реализовать кеширование шаблонов и собственно данных. Также обещают не превращать логику шаблонов в "ещё один PHP", и, возможно, выложат когда-нибудь в open-source (не выкладывают якобы потому что довольно нетипичная задача). Вот это конечно dark side стопудово. Господи, к чему кокетничать, типа, специфическая задача, не всем надо... Кому надо - станет использовать, станет популярным - значит, не зря открыли. Если говно - само умрёт, а если нет - само заживёт. Интеллектуальной ценности сам по себе шаблонизатор никакой не несёт. Не понимаю, в-общем. Выложат - будут молодцы. И никакой университет для малолеток не надо мутить - просто откройте не-бабло-образущий код, уже пойдет и трафик ценных кадров, и buzz.
Сервер приложений SUP Fabrik / Андрей Шетухин, Игорь Семенов (SUP Fabrik)
СУП, как известно, это всё, что уже годами пытается нас монетизировать. Когда СУП начинался, накупили сервисов, хороших и разных, ну и разумеется встал вопрос об интеграции этого добра. К тому же сейчас с СУПом имеют партнерские отношения многие компании, с сервисами которых также понадобилось тесно взаимодействовать (тот же Коммерсант, к примеру) - поэтому решили создать единую платформу для интеграции. В итоге выбрали схему, построенную на множестве серверов RPC (remote procedure call), через которые по собственному протоколу и происходит всё общение. Протокол текстовый, удобный для отладки, всего пять команд: handshake, call, response, error и ещё какой забыл. Для наиболее распространенных языков программирования есть интерфейсы к RPC. Утверждается, что в сам протокол заложена кластеризация, и система изначально полностью децентрализована. При старте системы каждый из RPC-демонов читает свою конфигурацию, устанавливает связь с бэк-эндами (насколько я понимаю это собственно сервера приложений, которые и надо интегрировать, но вроде и прикладной сервис тоже можно обучить понимать RPC), далее загружает список других RPC-серверов, они делятся друг с другом данными - таким образом каждый знает, какие команды (процедуры) на каком из серверов поддерживаются. Аналогичная процедура происходит при масштабировании (под какую-то задачу добиваем сервера). При поступлении запроса на сервер сначала происходит проверка, нельзя ли данную операцию выполнить локально, если нельзя - редирект (если несколько - автоматическая балансировка). Связи между серверами - каждый с каждым. Поддерживается двухуровневое кеширование: и на том сервере, на котором собственно выполнился запрос, и на том, который редиректит (сейчас меня мучают сомнения, что это правильно называть редиректом - потому что если есть кеширование неродных данных - значит это уже проксирование, а это в свою очередь уже опасно - о чём ниже). Отказоустойчивость достигается за счет того, что связи между серверами - каждый с каждым, и если вдруг потеряли соединение, то происходит автоматический reconnect, а если неудачно - удаляем из списка и оповещаем другие сервера кластера. Интеграция осуществляется так: ничего не портируем, просто оборачиваем вокруг RPC. Собирается это хозяйство почти на всех unix/linux, поскольку платформы и задачи очень разные и обычно это традиционный зоопарк. В будущем планируют опубликовать RFC на протокол для партнеров и, возможно, выложат в открытый доступ. Также планируется поддержка кластера кластеров, безопасная передача данных, и, наконец, open source реализация. Схема красивая. С точки зрения интеграции очень простая и удобная. Но вот огород вокруг "гетерогенности", что любой сервис может принять запрос на любую процедуру и отредиректить его на соотвествующий сервис, если не умеет, а ещё и закешировать результат - вот это уже какой-то ахтунг. Что касается отказоустойчивости, то мне в-общем тоже не до конца понятно. Альтернатива понятно какая - дедовская. Если у тебя есть какое приложение, ты взял и сохранил конфиг: ЭтаСтрашнаяБайда живёт на таком-то хосте - и раскидал по клиентам. Если ты добиваешь сервак - меняешь конфигурацию и раскидываешь по клиентам снова. Далее один из серваков упал - ты должен обновлять конфигурацию, либо клиент должен уметь пойти на другой сервак. Теперь другая ситуация: я хочу сделать плавное выключение упавших серверов (или наоборот плавное масштабирование). Значит если клиент не знает ничего о конфигурации и о том, кто жив, а кто нет - то он не может ходить напрямую на сервер, который может упасть, а должен ходить через прокси. Прокси должен знать, какие сервера участвуют в, держать соединения и отрубать трафик на те, которые упали. Прокси может быть несколько штук и тогда они должны обмениваться информацией. Чем тогда концептуально отличается ситуация с падением прокси во второй модной схеме от падения сервера в первой дедовской схеме? Ну, наверное, вероятность отказа действительно пониже, но зато при падении прокси отвалится бОльшее число клиентов, либо для прокси-схемы должно быть больше серверов. В-общем, не уверен я, что с практической точки зрения данная схема хороша. Почему просто нельзя раздать конфиги всем клиентам, если нужно - пусть каждая клиент (ну или проще - сервер, с которого может пойти удаленный запрос на выполнение процедуры) умеет плавно обновить данный конфиг (а это те же сбои или добивка серверов). Красиво, но по-моему перемудрили. Если мне в камент или в почту или куда угодно напишут, где я тут не прав - буду премного благодарен.
Как работает microsoft.com / Петр Диденко (Microsoft)
Петр не смог выступить, потому что катал по Москве важного гостя, который на этой же конференции рассказывал про какие-то хостинг-решения от Майкрософт (а я прогулял это дело). Выступал Гайдар Магдануров. В основном, доклад состоял из всякого рода цифр: 30 тысяч запросов в сутки, 20-30 Гбит/сек трафик, 7 датацентров, Microsoft Windows Server 2008 Beta 3 (всё, якобы, тестят на себе), ASP, .Net. потом стал рассказывать про то, что в новой Висте улучшена работа с TCP стэком, что приводит к 65-процентному увеличению утилизации сети. Потом была ещё куча каких-то мутных бенчмарков, по которым нужно было понять, что Vista и Microsoft Windows Server 2008 быстрее, выше, сильнее. Потом встал Сысоев и сказал, что бенчмарки ваши странные, 3000 get/сек делал FreeBSD на слабеньком железе лет 7 назад, и вообще, гет гету рознь, одно дело мелкая статика, другое дело порнуха не мелкая, в общем, выяснилось, что "это просто данные с сайта нашего вендора". В-общем, мне понравилось, было весело.
Больше я никуда не ходил, вернее ходил, но пить пиво в кафе, откуда все уже отправились на кораблик. Теперь, итоги. Мне в-общем было покласть на проколы организации, просто потому что я не заплатил за это дело ни копейки, и даже как член какого-то там комитета вообще палец о палец не ударил (а и не просили, кстати - не считая круглого стола на кораблике, который все равно мог быть интересен ислючительно паре десятков людей, кто столпился вокруг и кому было слышно-видно, и где по-моему единственное, что я сделал - попросил перестать называть nginx как нгинкс и нжинкс, потому что он эн-жин-икс, а lighttpd - не лайт-тэ-пэ-дэ, а лайти). Эта конференция по техническим докладам показалась мне сильнее РИТа. Мне понравилось, что много знакомых, с которыми можно просто выпить пива и потрещать. Мне понравилось, что народ стал охотнее рассказывать - что да как. Ну да, кругом велосипеды. А у вас-то у самих как, а? Главное в таких конференциях - общение. И чем его больше - тем лучше. Да, и я поддерживаю идею стендовых докладов. Взять всех, но половину, вторую половину - на стенды. Стенды пусть висят всё время, сама сессия вечером - кому интересно останется, и толкотни не будет. Короче, зовите меня ещё.
...
Какая удача, что вы продолжили читать дальше. Здесь у нас традиционное рекламное объявление, или другими словами галимый пеар. Нам по-прежнему нужны php/mysql разработчики. Работать в отличной команде, под моим руководством. Все контакты по ссылке, с удовольствием отвечу на любые вопросы.
Тюнинг операционных систем / Дмитрий Лоханский
Очень тяжело доклад на такую необъятную тему втиснуть в 45 минут, поэтому Дмитрий поступил разумно: прямо сразу начал рассказывать о параметрах настройки, которые могут значительно повлиять на производительность системы в целом, для трех принципиально важных "физических" компонента системы - памяти, диска и сети. Из-за того, что времени было совсем немного, докладу несколько не хватало академичности - всё-таки больше это было похоже на некоторый перечень имен констант, которые можно как-нибудь покрутить, чтобы что-нибудь поменялось. В материалах текста чуть больше, но зато куда-то пропали некоторые конфигурационные параметры, которые были на слайдах. Некоторые важные аспекты не были затронуты, например ничего не было сказано ни о планировщике, ни о context switches (важные темы для тюнинга веб-тачек), но что ещё важнее - как мониторить систему через всякие *stat. Вряд ли стоит в этом упрекать докладчика, нехватка времени - дело сёрьезное. В-общем если сложить это всё вместе, то получается вполне себе картина, и если, например, новичку с ней разобраться, думаю этого вполне будет достаточно чтобы задать дальнейший вектор для. Если автор сможет собрать воедино части из презентации и из материалов и добавит описание основных инструментов администратора, при помощи которых можно вообще посмотреть, что же у нас в системе происходит - по-моему это будет очень неплохой учебный курс, который нужен многим администраторам и в особенности разработчикам (которые к сожалению в массе своей вообще не представляют, как оно всё работает внутри). Поэтому один из первых вопросов докладчику был о том, а можно ли всё это дело где-нибудь прочитать. На что докладчик ответил что-то в духе RTFM, и хотя по большей части это верно, я всё-таки хочу заметить, что есть очень неплохая книжка Мусумеси и Лукидеса, которую было бы не грех в таких случаях рекомендовать - Настройка производительности UNIX-систем. Там правда больше про Sparc/Solaris, но есть кое-что и про Linux (и увы - ничего о FreeBSD), но зато она очень помогает понять, как там всё внутри живет, как это хозяйство мониторить и тюнить.
Сетевая многозадачность: событийные машины / Павел Кудинов
Павел не раз открыто говорил: я, ребята, поисковый спамер. А спамеры - они хитрые. И задачи у них есть ой какие интересные. Доклад произвел на меня двойственное впечатление. С одной стороны тема отличная, и содержание в-общем хорошее, рассказал всё бойко, начал издалека, о prefork/worker, тредах и мультиплексировании (это и есть снова событийных машины, если кто не понял - короче всё, что делает select, poll и прочие kqueue/epoll), затем рассказал про libevent и POE (libevent - всем известная билиотека на Си для обработки сетевых соединений, а POE - фреймворк на Perl, ипользуется для написания разного рода сетевых сервисов (раньше я тут написал что POE поверх libevent - это неверно, спасибо quappa), очень мощная и удобная штука, кстати). Даже успел рассказать немного об архитектуре прикладных сервисов с использованием этого добра и их кластеризации (спамерское, разумеется - сборщик ответов от каких-то там сервисов). С другой стороны, на системном уровне как-то всё было очень бегло, а местами по-моему просто неверно. К сожалению, я не могу вспомнить конкретно, где были косяки, потому что в материалах ни схем из презентации, ни некоторых разделов просто не было, лишь помню, что меня например насторожили фразы о модели обработки сетевых соединений апачём, где мастер якобы там что-то принимал и передавал воркеру, ну или что-то в этом духе. Что касается практических примеров, то с аналитической и ахитектурной точки зрения всё это хозяйство конечно представляло интерес для слушателей, но паталогическое желание докладчика называть элементарнейшие вещи сложными умными словами заставляло меня буквально продираться сквозь этот поток к совершенно простым и понятным вещам (попробуйте прочитать текст презентации из материалов конференции, и вы поймёте, о чём я). Короче. И тема хорошая, и содержание хорошее, но над подачей надо бы поработать. В первую очередь - быть проще. Никакого rocket science тут нету. Чуть больше времени уделить обзору моделей обработки сетевых соединений - снова будет хороший учебный доклад.
Кластерные параллельные вычисления / Владислав Шабанов (РБК-Медиа Мир/Вертикальный поиск)
Владислав в прошлом был одним из ведущих разработчиков Рамблера. Насколько я понимаю, с недавних пор (вернее, с тех пор, как с Рамблером в очередной раз случились разного рода перемены) - руководитель группы "Вертикальный поиск", каким-то загадочным образом сотрудничающей с РБК (похоже, скоро поиск будет у всей большой четвёрки). Доклад был о том, как на основе нескольких базовых примитивов ("реляционные" таблицы) и операций над ними (слияние, расщепление, фильтрация, сортировка и проч.) реализовать паралельные вычисления для тех задач, когда для расчетов приходится использовать кучу машин, и на каждой машине данных столько, что уместить их в память обычно не представляется возможным. Всё вместе это называется чудесным термином S3M2J, что соотвествует базовым операциям над таблицами: sort, split, scatter, merge, map, join. Например, задача распределенного сохранения объектов решается примерно по следующей программе: взяли порцию данных, порезали (split), отсортировали (sort), отправили на сервера в кластере (scatter), и там соединили с тем, что лежало раньше (join). Все примитивы реализуются библиотекой на С++, есть XS-интерфейс к Perl. На основе данного фреймворка реализован поисковый движок и статистика Рамблера, а также ряд других задач. Система "полна" в математическом смысле, то есть в рамках этого подхода могут быть решены практически любые задачи. Всё это очень напоминает и MapReduce, и Hadoop; хорошо масштабируется и оптимально использует диски (почти всё строго сортировано, последовательные чтение-запись), но похоже, что пока не начнешь с этим работать вплотную, не прочуствуешь. На мой вопрос о том, будет ли пущен этот фреймворк в open source автор ответил что-то в духе, мол, хрен его знает, массовому пользователю это не надо - но будет пущено, если будет спрос со стороны других открытых исследовательских проектов. Так что если вы представляете такой проект - можете попробовать получить исходники. В общем, такой исключительно концептуальный доклад, весьма интересно, но поскольку нельзя ничего скачать-потрогать и посмотреть конкретные примеры - лично у меня осталось некоторое недопонимание.
Использование nginx как сервера-сборщика / Андрей Баранов, Денис Ерыгин (Mail.RU)
Когда я прочитал название этого доклада, я задумался: что же собирает nginx? мусор? бутылки? подати? Оказывается, собирает он HTML. Ребята взяли ctpp - шаблонизатор на C++, который давно использовался в Мейле - и вкрутили это хозяйство модулем в nginx. Предыстория вопроса простая: портальные страницы состоят из кучи разны кусков, которые обычно отвечают совершенно разным приложениям. Nginx очень быстро умеет SSI, и даже умеет SSI с удаленного хоста, но до полноценного шаблонизатора ему далеко (здесь раньше я ошибся, написав, будто nginx не умеет SSI удаленно, и меня поправили в каментах __si__ и proforg). Поэтому архитектура следующая: с удаленного хоста взяли данные (используется формат JSON, как наиболее простой для парсинга), а nginx просто "накладывает" на это дело шаблонное преобразование. С одной стороны, шаг не очень логичный: nginx всё-таки быстрый веб-сервер, и нефиг на него накладывать какую-то логику, плюс делать самостоятельно запросы на внешние сервера (точнее, делать-то можно, только это надо делать крайне аккуратно, потому что малейший косяк затормозит всю систему к чертовой матери). С другой стороны, обычно на фронтендах, если на них ничего не крутится, простаивает проц, и если перенести нагрузку по оборачиванию данных в шаблоны с бэк-ендов, то в-общем можно перераспределить нагрузку и более грамотно использовать ресурсы системы. На мой вопрос о целесообразности данного решения ответили "у нас всё круто", но я конечно ожидал, что докладчики смогут предоставить данные о том, каким макаром в их конфигурации при переносе "сборки" страниц на фронтенды понизилась нагрузка на бэкенды, и насколько она подросла на фронтендах. Собираются реализовать кеширование шаблонов и собственно данных. Также обещают не превращать логику шаблонов в "ещё один PHP", и, возможно, выложат когда-нибудь в open-source (не выкладывают якобы потому что довольно нетипичная задача). Вот это конечно dark side стопудово. Господи, к чему кокетничать, типа, специфическая задача, не всем надо... Кому надо - станет использовать, станет популярным - значит, не зря открыли. Если говно - само умрёт, а если нет - само заживёт. Интеллектуальной ценности сам по себе шаблонизатор никакой не несёт. Не понимаю, в-общем. Выложат - будут молодцы. И никакой университет для малолеток не надо мутить - просто откройте не-бабло-образущий код, уже пойдет и трафик ценных кадров, и buzz.
Сервер приложений SUP Fabrik / Андрей Шетухин, Игорь Семенов (SUP Fabrik)
СУП, как известно, это всё, что уже годами пытается нас монетизировать. Когда СУП начинался, накупили сервисов, хороших и разных, ну и разумеется встал вопрос об интеграции этого добра. К тому же сейчас с СУПом имеют партнерские отношения многие компании, с сервисами которых также понадобилось тесно взаимодействовать (тот же Коммерсант, к примеру) - поэтому решили создать единую платформу для интеграции. В итоге выбрали схему, построенную на множестве серверов RPC (remote procedure call), через которые по собственному протоколу и происходит всё общение. Протокол текстовый, удобный для отладки, всего пять команд: handshake, call, response, error и ещё какой забыл. Для наиболее распространенных языков программирования есть интерфейсы к RPC. Утверждается, что в сам протокол заложена кластеризация, и система изначально полностью децентрализована. При старте системы каждый из RPC-демонов читает свою конфигурацию, устанавливает связь с бэк-эндами (насколько я понимаю это собственно сервера приложений, которые и надо интегрировать, но вроде и прикладной сервис тоже можно обучить понимать RPC), далее загружает список других RPC-серверов, они делятся друг с другом данными - таким образом каждый знает, какие команды (процедуры) на каком из серверов поддерживаются. Аналогичная процедура происходит при масштабировании (под какую-то задачу добиваем сервера). При поступлении запроса на сервер сначала происходит проверка, нельзя ли данную операцию выполнить локально, если нельзя - редирект (если несколько - автоматическая балансировка). Связи между серверами - каждый с каждым. Поддерживается двухуровневое кеширование: и на том сервере, на котором собственно выполнился запрос, и на том, который редиректит (сейчас меня мучают сомнения, что это правильно называть редиректом - потому что если есть кеширование неродных данных - значит это уже проксирование, а это в свою очередь уже опасно - о чём ниже). Отказоустойчивость достигается за счет того, что связи между серверами - каждый с каждым, и если вдруг потеряли соединение, то происходит автоматический reconnect, а если неудачно - удаляем из списка и оповещаем другие сервера кластера. Интеграция осуществляется так: ничего не портируем, просто оборачиваем вокруг RPC. Собирается это хозяйство почти на всех unix/linux, поскольку платформы и задачи очень разные и обычно это традиционный зоопарк. В будущем планируют опубликовать RFC на протокол для партнеров и, возможно, выложат в открытый доступ. Также планируется поддержка кластера кластеров, безопасная передача данных, и, наконец, open source реализация. Схема красивая. С точки зрения интеграции очень простая и удобная. Но вот огород вокруг "гетерогенности", что любой сервис может принять запрос на любую процедуру и отредиректить его на соотвествующий сервис, если не умеет, а ещё и закешировать результат - вот это уже какой-то ахтунг. Что касается отказоустойчивости, то мне в-общем тоже не до конца понятно. Альтернатива понятно какая - дедовская. Если у тебя есть какое приложение, ты взял и сохранил конфиг: ЭтаСтрашнаяБайда живёт на таком-то хосте - и раскидал по клиентам. Если ты добиваешь сервак - меняешь конфигурацию и раскидываешь по клиентам снова. Далее один из серваков упал - ты должен обновлять конфигурацию, либо клиент должен уметь пойти на другой сервак. Теперь другая ситуация: я хочу сделать плавное выключение упавших серверов (или наоборот плавное масштабирование). Значит если клиент не знает ничего о конфигурации и о том, кто жив, а кто нет - то он не может ходить напрямую на сервер, который может упасть, а должен ходить через прокси. Прокси должен знать, какие сервера участвуют в, держать соединения и отрубать трафик на те, которые упали. Прокси может быть несколько штук и тогда они должны обмениваться информацией. Чем тогда концептуально отличается ситуация с падением прокси во второй модной схеме от падения сервера в первой дедовской схеме? Ну, наверное, вероятность отказа действительно пониже, но зато при падении прокси отвалится бОльшее число клиентов, либо для прокси-схемы должно быть больше серверов. В-общем, не уверен я, что с практической точки зрения данная схема хороша. Почему просто нельзя раздать конфиги всем клиентам, если нужно - пусть каждая клиент (ну или проще - сервер, с которого может пойти удаленный запрос на выполнение процедуры) умеет плавно обновить данный конфиг (а это те же сбои или добивка серверов). Красиво, но по-моему перемудрили. Если мне в камент или в почту или куда угодно напишут, где я тут не прав - буду премного благодарен.
Как работает microsoft.com / Петр Диденко (Microsoft)
Петр не смог выступить, потому что катал по Москве важного гостя, который на этой же конференции рассказывал про какие-то хостинг-решения от Майкрософт (а я прогулял это дело). Выступал Гайдар Магдануров. В основном, доклад состоял из всякого рода цифр: 30 тысяч запросов в сутки, 20-30 Гбит/сек трафик, 7 датацентров, Microsoft Windows Server 2008 Beta 3 (всё, якобы, тестят на себе), ASP, .Net. потом стал рассказывать про то, что в новой Висте улучшена работа с TCP стэком, что приводит к 65-процентному увеличению утилизации сети. Потом была ещё куча каких-то мутных бенчмарков, по которым нужно было понять, что Vista и Microsoft Windows Server 2008 быстрее, выше, сильнее. Потом встал Сысоев и сказал, что бенчмарки ваши странные, 3000 get/сек делал FreeBSD на слабеньком железе лет 7 назад, и вообще, гет гету рознь, одно дело мелкая статика, другое дело порнуха не мелкая, в общем, выяснилось, что "это просто данные с сайта нашего вендора". В-общем, мне понравилось, было весело.
Больше я никуда не ходил, вернее ходил, но пить пиво в кафе, откуда все уже отправились на кораблик. Теперь, итоги. Мне в-общем было покласть на проколы организации, просто потому что я не заплатил за это дело ни копейки, и даже как член какого-то там комитета вообще палец о палец не ударил (а и не просили, кстати - не считая круглого стола на кораблике, который все равно мог быть интересен ислючительно паре десятков людей, кто столпился вокруг и кому было слышно-видно, и где по-моему единственное, что я сделал - попросил перестать называть nginx как нгинкс и нжинкс, потому что он эн-жин-икс, а lighttpd - не лайт-тэ-пэ-дэ, а лайти). Эта конференция по техническим докладам показалась мне сильнее РИТа. Мне понравилось, что много знакомых, с которыми можно просто выпить пива и потрещать. Мне понравилось, что народ стал охотнее рассказывать - что да как. Ну да, кругом велосипеды. А у вас-то у самих как, а? Главное в таких конференциях - общение. И чем его больше - тем лучше. Да, и я поддерживаю идею стендовых докладов. Взять всех, но половину, вторую половину - на стенды. Стенды пусть висят всё время, сама сессия вечером - кому интересно останется, и толкотни не будет. Короче, зовите меня ещё.
...
Какая удача, что вы продолжили читать дальше. Здесь у нас традиционное рекламное объявление, или другими словами галимый пеар. Нам по-прежнему нужны php/mysql разработчики. Работать в отличной команде, под моим руководством. Все контакты по ссылке, с удовольствием отвечу на любые вопросы.