Блог им. AnganarАрхитектура корпоративной ИС на базе открытого ПО

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

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

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

Документ выложен здесь — http://avasyukov.blogspot.com/2010/01/blog-post.html.
Комментарии и конструктивная критика приветствуются.

P.S. Кросс-пост из личного блога avasyukov.blogspot.com/
  • +6
  • Anganar
  • 13 января 2010, 14:06

Комментарии (13)

Тема сверхинтересная. Документ концептуален. На его основе можено даже учебную программу по Open Source сделать. Всяческий Вам за эту работу респект.
Только хотелось бы иметь возможность как-то этот документ поиметь в более удобном для работы формате.
Ссылка в ответах ниже пойдет?
  • avatar
  • the
  • 13 января 2010, 16:49
  • #
  • 0
чтобы скачать надо регаться там…
выложте куда-нибудь файлик, чтоб без рега скачать
У меня еще забавно происходит прокрутка документа в просмоторщике. По вертикальному скролу он одновременно и документ скролит, и окно браузера. Зато по горизонтальному скролу все норм. Хотя может это нормально пока окно браузера некуда скролить...)
Упс. Прошу прощения — проверял ссылку залогиненным и не заметил, что оно требует регистрации. Выложил здесь.
  • avatar
  • SPU
  • 13 января 2010, 20:42
  • #
  • 0
Каким образом предполагается увеличивать производительность БД за счет добавления машин в кластер?
Смотрел невнимально, но вроде предполагается независимость от используемой БД. Имеется в виду, что в конечном проекте можно использовать любую или что БД можно заменить не меняя ничего в остальной системе (кроме настроек)?
Весь документ ориентирован на стек из вполне конкретных продуктов. В этом суть задачи, из которой он возник, — вместо позиции «все возможно, есть много инструментов и т.д.» дать предельно конкретный работающий стек.

В роли СУБД здесь — EDB/Postgres. Горизонтальное масштабирование — средствами GridSQL (http://www.enterprisedb.com/community/projects/gridsql.do).

Насчет заменяемости компонент (СОА, интероперабельность и все подобные правильные слова) — мысли поработать в эту сторону есть, но сил пока не хватает.
Интересно было бы попытать GridSQL под высокой нагрузкой, но боюсь, что для моих задач все упрется в ограничения сети между нодами, т.к. не представляю себе, как можно в автоматическом режиме произвести оптимальную кластеризацию БД, с которой нужно работать. Жаль только кластер пока не на чем развернуть…
У нас сейчас не хватает сил делать все и сразу… Но в планах обзор этого есть. Как будет что-то более-менее законченное — выложим.
Было бы интересно.
P.S. Боюсь, что у меня слишком специфические задачи для GridSQL, но попробовать стоит.
А какие задачи?
У меня фактически две БД. Грубо говоря, БД неких настроек (не шибко большая, но запросы к ней идут сложные), и БД архива, куда идет непрерывная запись довольно большими темпами, причем на каждую такую запись нужно сделать хитрую выборку из БД настроек и из этой же БД архива. Т.е. новые данные преобразовываются на основе настроек и на основе последних данных из архива (для скорости хранятся отдельно), по этой причине последовательность записи в БД должна строго сохраняться. Из-за такой особенности обычное разделение потока данных по нодам с отложенной синхронизацией БД не проходит.
К данным архива как раз можно применить горизонтальную кластеризацию, но даст ли это какое-то преимущество? Т.к. моя проблема не в тяжести запросов, а в их количестве и взаимосвязанности, ну и само собой архивная БД имеет огромные объемы + нагрузка от пользователей, которые как раз делают тяжелые запросы в архив.
Картину понял. Как говорится, с этой мыслью надо переспать… Если что хорошее придет в голову — дам знать.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.