Доросли мы до задачи планирования развития информационной инфраструктуры. С учетом теперешних модных технологий виртуализации, blade-ферм и т.д. Планирование на три-пять лет вперед. Мне был задан вопрос о целесообразности сведения (консолидации) баз данных предприятия в единую БД, либо о сосредоточении баз данных различных приложений на одном сервере.
Т.е. у руководства в голове засела централизация и мнение, что мы выкинем все маленькие серверы (разнопёрые, конечно же ;-)) и все установим на одном дорогом и мощном серваке.
Пытаюсь подсчитать плюсы и минусы разных подходов.

О структуре инф. систем предприятия: используется подход "производственная БД" - "стендбай" - "тестовые БД", причем практикуется подход, при котором стендбаи располагаются рядом с тестовыми инстанциями. Парк баз данных: Oracle, Microsoft SQL. Операционные системы: Solaris, Windows, Linux. Кластерные технологии до сих пор не использовались, но подсистемы, требующие кластеризации имеются. Используется две гермозоны (серверные), разнесенные географически (в пределах города) и между собой имеют локальную сеть (оптоволокно).

Варианты виртуализации - зоны в Solaris, Oracle VM, MS Hyper-V, FlexFrame ... еще варианты?

Варианты подходов:

Централизация (все на одном сервере, но БД не сведены в единую БД):
+ упрощение (и, следовательно, удешевление) администрирования
- неизвестно, как уживутся различные серверные части приложений друг с другом (проблема совместимости)
- одна большая точка отказа, следовательно, железо и системное ПО дорогое, нужна очень надежная отказоустойчивость
+ в случае, если приобретать железо для тестовых целей не очень скупясь, то проблем с тестовыми инстанциями, с железом для новых, тестируемых, систем проблем быть по идее не должно
- в случае перезагрузки или остановки сервера ВСЕ системы перестают работать на некоторое время
- как уже упоминал, некоторые системы требуют кластеризации. Это значит, что на кластер попадут и системы, которые кластеризации не требуют

Централизация (все БД сведены в единую):
+ упрощение администрирования
- одна точка отказа - дорогая отказоустойчивость
- в случае перезагрузки или остановки сервера или БД, ВСЕ системы перестают работать

Для любой централизации:
- многократное усложенение контроля безопасности, т.к. прописывать доступы различным админам к одному и тому же железу и ОС - занятие трудоемкое.
+ в случае использования виртуализации - предыдущий минус снимается.
- в случае использования виртуализации будет ли достаточно эффективно использоваться железо - большой вопрос, т.к. соответствующего опыта нет.

Децентрализация:
(до сих под использовался подход "одно приложение - один сервер". Т.е. если приложение клиент-серверное, то в качестве сервера БД используется отдельный сервер. Если добавляется сервер приложений - он также устанавливается на отдельном сервере)
+ администрирование доступа к серверам
+ возможность использования дешевого (сравнительно) железа для нересурсоемких задач, например, для MS AD - 2-3 рэковых доменных контроллера
- зоопарк серверов


В процессе обсуждения выплыла мысль - разбить ПО на категории и в соответствии с этими категориями группировать ПО для использования железа. Например, системы с требованиями по высокой доступности, отказоустойчивости и масштабируемости разместить на кластере (дорогое брендовое железо, в общем). Но, всплывает минус - что делать с тестовыми инстанциями? Предприятие достаточно большое (2 тыс. сотрудников), поэтому обычно тестовых инстанций требуется как минимум 2 - для собственных разработчиков, пишущих внутренние доработки и отчеты, и для внешних поставщиков - обновления, плановые доработки и т.д. Желательно, естественно, чтобы тестовое железо было близко к реальному из соображений корректного тестирования. В настоящее время используется подход, при котором к резервной инстанции подсаживается одна-две тестовых. Сервер для этого приобретается, естественно, с бОльшим количеством дискового пространства (storage) и оперативки. Таким образом, мы можем протестировать изменения в условиях, близких к реальным.

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

Petro123,

букв действительно много...

Не сочтите, что оправдываюсь, но речи о сведении ИС в одну речи не было. Имела место быть речь об объединении БД различных ИС или расположение различных БД (инстанций) и Application Servers на одном физическом сервере.

букв достаточно мало?

_модD_i_m Мне был задан вопрос о целесообразности сведения (консолидации) баз данных предприятия в единую БД
В терминологии oracle по убыванию "правильности":
1. единая БД (с подсхемами)
2. распределенная БД с dblink
...

да, подобный опыт имеется и у меня, т.е. сводились в одну базы данных двух приложений, и dblink также широко используется.
Хотелось бы услышать опыт тех, кто на практике занимался централизацие либо инстанций либо баз данных всего предприятия. Хотя вопрос немного для меня несколько шире - объединение не только БД, но и вообще любой серверной части прикладных систем на одном железе.

Например, у нас, после объединения баз данных двух приложений возникла проблема при замене одного из этих приложений на другое, поскольку держать БД с данными "умершего" приложения нецелесообразно (данных порядка 600 Гб, а дисковый массив дорогой), то придется либо опять выделять БД в отдельную инстанцию, либо сращивать со следующей БД. С одной стороны ничего невыполнимого в этом нет, но со временем два приложения переплелись (т.е. взаимно используются хранимые объекты) и разделение систем теперь представляет не то чтобы проблему, но не совсем тривиальную задачу.

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