Главная > Open Source, web2.0, веб-обзоры, Высокопроизводительная архитектура > Мониторинг сетевых параметров в распределенных архитектурах: X-Trace

Мониторинг сетевых параметров в распределенных архитектурах: X-Trace

2 апреля 2008

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

Сегодня расскажу вам о проекте, позволяющем следить и чутко реагировать на любые возникшие проблемы в вашей сетевой архитектуре. Создатели, RAD Lab (Reliable Adaptive Distributed Systems Laboratory), подготовили проект под названием X-Trace (не путать с популярным пакетом для отладки Flash-приложений), который они сами называют сетевым фреймворком, для постоянного мониторинга всех сервисов и серверов, которые составляют вашу архитектуру, на предмет возникновения каких-либо проблем.

Система мониторинга работает на достаточно высоком уровне, затрагивая протоколы IP, TCP, HTTP и другие. Сам мониторинг осуществляется путем добавления специального мета-тега, который в дальнейшем при прохождение запроса через сервис, на котором установлен агент сбора информации, позволяет отследить каждый запрос, даже если они комплексные. Например, клиент посылает первый запрос по HTTP к веб-серверу, далее этот запрос передается на балансировщик нагрузки, при этом он после поступления на первый же фронт-енд сервер начинает отслеживаться. Далее, после балансировщика, запрос пересылается серверу обработки, например, РНР Application server-у,  далее скрипт требует выполнения запроса данных от SQL-базы, соответственно также формируется запрос к СУБД, который также является частью одной транзакции и также отслеживается.

arch_overview.png

Вся информация от развернутых на узлах агентов стекается (по протоколу UDP)  на демон отчетов (Reporting deamon), который генерирует совокупный отчёт, который пересылается на бек-енд инфраструктуру и там хранятся, анализируются и доступны для администратора.

Сам по себе, бек-енд содержит достаточно серьезную инфраструктуру - он как принимает все отчеты, так и может посылать команды демону отчетов. Кроме этого, он сам содержит несколько серверов, например, LDAP (или связывается с внешним сервером) для получения конфигурации и прав, PostgreSQL сервер для хранения данных, а также встроенный Apache для визуализации данных, также поддерживается запрос и работа с данными через протокол XML-RPC, что удобно для построения на этой основе более масштабных решений и аналитических инструментов. Все отчеты от демонов сначала поступают в очередь сообщений, реализованную на Java (Java Messaging Service), что, в частности, позволяет использовать для обмена данными и защищенные протоколы.

backend_overview.jpg

Кстати, X-Trace используется в проекте Hadoop (вернее, может работать как часть платформы), который предназначен для построения распределенной системы хранения и обработки больших объемов данных.

На текущем этапе развития имеется две версии фреймворка -  1.3 как уже стабильная и зарекомендовавшая себя система и новая, версии 2.0, которая обладает широкими возможностями, новыми API (например, на Java для совместной работы с корпоративными приложениями и системами).

Подробнее про систему вы сможете почитать на ее веб-сайте и вики. Я же хочу сказать, что фреймворк достаточно интересен и актуален для различных сервисов и систем, требующих для своей работы бесперебойной связи между узлами и серверами. И пусть задумывая новый стартап, вы ограничиваете себя одним сервером, но по мере развития своей системы вы все чаще и чаще станете задумываться о расширении и балансировке нагрузки. А так как первым и самым действенным шагом будет вынесение различных частей на разные сервера, то здесь сразу возникнет вопрос и управления этой массой серверов, и постоянного мониторинга и другие совершенно специфические вопросы и проблемы. Поэтому стоит изначально планировать и использовать современные и проверенные системы для обеспечения стабильной работы вашего приложения. И X-Trace это именно такая система.

  1. 4 апреля 2008 в 12:51 | #1

    очень хорошо что с Hadoop можно использовать. Выглядет немного тяжеловатым на первый взгляд.

  2. 4 апреля 2008 в 12:54 | #2

    о, какие люди, из самого gwt.org.ua.. приятно, что нас там читают.

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

  3. 4 апреля 2008 в 13:09 | #3

    🙂 приятно, что нас читают из abrdev.com.

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

  4. 4 апреля 2008 в 13:14 | #4

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

  5. 4 апреля 2008 в 13:27 | #5

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

  6. 4 апреля 2008 в 13:33 | #6

    нет, мы говорим о третьем 🙂 обычные блейд-сервера в стойке, которые по 3 — 5 — 8 К всего стоят или арендуются за смешные 40 — 100 баксов. для мониторинга сервера за 50 баксов много больше, чем достаточно.

  7. 4 апреля 2008 в 13:46 | #7

    куча кайфа на 100 $ 🙂 у автора есть опыт работы с нагруженной распределенной работающей системой ? (интересно было бы узнать о нагрузках, параметрах серверов и т.д., можно уже в email)

  8. 4 апреля 2008 в 14:02 | #8

    хорошо, следующие сервера вполне достаточные для типичных проектов (в смысле, нужно — ставим два/три/пять серверов и налаживаем систему на них, модернезируем их, например, память доставляем и порты — ну это мелочи уже):

    Core 2 Duo/2Гб РАМ,2х 250 Гб диски. — 170 (но можно и дешевле конечно).
    далее:
    Core 2 Quad/4Гб РАМ/2х 250 Гб — чуточку дороже.
    далее:
    Core Quad 2,4GHz (Q6600), 8Gb RAM, 2?750Gb — 230
    2?Xeon Dual Core 1.60 GHz (5110), 4?1Gb FBDimm RAM, 4?72gb RAPTOR HDD SATA , RAID (c возможностью организации RAID 0, 1, 5, 10) — дороже, но примерно рамки.

    теперь назовите типичные веб-приложения (ясно, что не банк и т.п.), которым нужно больше, чем 1 — 2 — 5 серверов такой конфигурации или немного кастомной (в зависимости от специфики). Больше половины серверов википедии примерно аналогичные (память может расширятся до 8 Гиг, так как там часто кеш и сервера на одном и том же сервере, и они разделяют память наполовину). И в знакомом нам дигге подобные сервера.

    да, не беспокойтесь, есть у автора некоторый опыт 🙂 конечно, я не админ, но понимаю, о чем говорю.

  9. 4 апреля 2008 в 14:12 | #9

    спасибо за информацию 🙂 очень полезно.

  10. 12 июля 2008 в 11:32 | #10

    Спасибо ха полезную инфу

Комментирование отключено.