Как собрать оракловый сервер для крупной БД?

Требуется собрать аппаратную и программную платформу для развёртывания мощного ораклового сервера федерального уровня. Предполагается БД размером несколько Тб и электронный архив сканированных документов по одним данным 100Тб, по другим - 400. В качестве операционной системы будет выбран, скорее всего, 6 RHEL, в качестве аппаратной платформы начальство выдвигает HP BladeSystem c7000 Enclosure.
Тут возникают варианты, как это собрать. Взять в блэйд пару-тройку самых мощных лезвий и поднять на них БД самых "тяжёлых" городов, а на остальных лезвиях поменьше поднять "лёгкие" БД. Другой вариант - поставить одинаковые лезвия и все их объединить неким софтом в одно глобальное мощное облако, в котором крутились бы все нужные БД, разделяя все ресурсы между собой.
Второй вариант мне нравится существенно больше первого, но он пораждает и больше вопросов. Какой софт поднимет это облако? Насколько быстро и эффективно оно станет работать? Какие будут потери производительности по сравнению с 1 вариантом? Насколько устойчивым к выходу из строя единичных лезвий оно окажется?

Другая сторона проблемы - хранение электронного архива. Пока точно не известно, что он будет собой представлять, но, скорее всего, это будет либо отдельная таблица БД, либо отдельная оракловая база. Имея недорогие 600Гб винчестеры HP, как собрать такое хранилище с обеспечением требуемой избыточности и резервированием? Именно резервирование на какие-либо носители представляется менее всего перспективным в вопросе подобного электронного архива. Нужна схема сохранения информации без резервного копирования. Какая?
  • Вопрос задан
  • 3569 просмотров
Пригласить эксперта
Ответы на вопрос 7
foxmuldercp
@foxmuldercp
Системный администратор, программист, фотограф
Обратитесь к профессионалам интеграторам, это будет проще, дешевле и быстрее т.к. всё равно Вы самостоятельно вряд ли сможете так настроить аппаратную, программную часть и сам оракл, чтобы он хорошо держал высокие нагрузки, не падал и вообще не отсвечивал в предупреждениях системы мониторинга.

Опять же, много всяких подводных камней в HCL листах, а те же Dell. HP, IBM уже явно и не один десяток раз решали такие проблемы, поэтому готовые решения таких маститых монстров явно учтут и Ваши требования и те требования, о которым Вы можете и не знать на данный момент.
Ответ написан
Комментировать
Awake
@Awake
Рулю разработкой ;-)
Хочется верить, что вы спрашиваете в образовательных целях, а не собираетесь по мануалам и ответам на тостере собирать сервак для такой БД.
Ответ написан
Комментировать
Qwadrat
@Qwadrat
Поддерживаю, считаю что блэйд - совсем не то, что вам нужно. Вам нужно 1-2 мощных сервера и нормальную СХД. Любой системный интегратор вам быстренько составит ТКП под такую задачу. Определитесь только, какая ОС у вас будет - если Linux, то брать SPARC нет смысла.
Ответ написан
Комментировать
@STrojan
1. Так-же не забывайте 6 RHEL не проходит по матрице совместимости с Oracle 11gR2
2. СХД лучше брать внешнее с поддержкой FC.
3. Сервера надо брать с оглядкой на ПО, для поддержки несколько БД
Ответ написан
harbid
@harbid Автор вопроса
admin
Я спросил в надежде получить от опытных людей советы и хинты. Так сказать, направление. От начальства пришла директива - подобрать конфиг HP BladeSystem c7000 Enclosure, подходящий для нашей задачи. Я понял, что этот девайс подходит слобовато. Так что, по итогу, что поставит федеральный центр, на том и будем работать. Или мучиться. Всем спасибо за (со)участие!
Ответ написан
Комментировать
Qwadrat
@Qwadrat
Позволю себе немного пофантазировать. Если уж никуда от блэйдов не деться, возможно стоит попробовать поднять RAC со всеми активными нодами. Плюс в том, что между блэйдами проще организовать быстрый интерконнект. Основная проблема в этом случае - грамотно спроектировать БД, чтобы по минимуму использовать интерконнект между нодами кластера. Ну и конечно без СХД вам не обойтись.
Ответ написан
А есть требования по отказоустойчивости, простою?

Если требуется 24х7, то либо создавать для каждой базы Standby, либо поднимать RAC. С RAC'ом, насколько я слышал (сам не реализовывал), бывает очень много странных танцев с бубном, но зато вы получите балансировку нагрузки + устойчивость к отказам (если приложение сможет работать с RAC, оперативно переключаясь на другую ноду).

По поводу хранения - если у вас не High-end СХД с хорошими вычислительными мощностями, то лучше собирайте 1+0; если случится авария на 5 или 6, то велик риск смерти еще одного диска в группе, пока на Hot spare будут восстанавливаться данные; скорее всего, 600 Gb винчестеры у вас SATA и около 7200 rpm, так что они будут очень медленные.

В любом случае, бэкапы стоит продумать, хотя бы редкие; даже имея хорошую СХД и RAID большой избыточности, вы не застрахованы от смерти контроллера.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы