Требуется собрать аппаратную и программную платформу для развёртывания мощного ораклового сервера федерального уровня. Предполагается БД размером несколько Тб и электронный архив сканированных документов по одним данным 100Тб, по другим - 400. В качестве операционной системы будет выбран, скорее всего, 6 RHEL, в качестве аппаратной платформы начальство выдвигает HP BladeSystem c7000 Enclosure.
Тут возникают варианты, как это собрать. Взять в блэйд пару-тройку самых мощных лезвий и поднять на них БД самых "тяжёлых" городов, а на остальных лезвиях поменьше поднять "лёгкие" БД. Другой вариант - поставить одинаковые лезвия и все их объединить неким софтом в одно глобальное мощное облако, в котором крутились бы все нужные БД, разделяя все ресурсы между собой.
Второй вариант мне нравится существенно больше первого, но он пораждает и больше вопросов. Какой софт поднимет это облако? Насколько быстро и эффективно оно станет работать? Какие будут потери производительности по сравнению с 1 вариантом? Насколько устойчивым к выходу из строя единичных лезвий оно окажется?
Другая сторона проблемы - хранение электронного архива. Пока точно не известно, что он будет собой представлять, но, скорее всего, это будет либо отдельная таблица БД, либо отдельная оракловая база. Имея недорогие 600Гб винчестеры HP, как собрать такое хранилище с обеспечением требуемой избыточности и резервированием? Именно резервирование на какие-либо носители представляется менее всего перспективным в вопросе подобного электронного архива. Нужна схема сохранения информации без резервного копирования. Какая?
Не хватает данных.
1) Как будут изменяться данные?
2) Какие требования к надежности базы и времени восстановления?
3) Вариант с "облаком" несколько сказочен. Почитайте про Hadoop и MapReduce в ознакомительном порядке.
4) Если уж база федерального уровня, то нужен и stand-by и backup.
Если встают такие вопросы, то возможно стоит рассмотреть вариант покупки железки Оракл? А лучше всего к системному интегратору обратиться. Думается мне что 7000 не совсем та платформа для БД...
Архив будет постоянно расти. Пришёл человек с документами, их сосканировали и в архив. Надо обратиться к документам - обратились в архив. Потенциально, возможно обращение к любому документу в архиве, но, скорее, к разным документам. К одним и тем же очень редко.
Надёжность нужна очень высокая. Документы денежные.
Время восстановления - порядка единиц часов, простои вообще не желательны. Хоть и работа с БД предполагается, в основном, в рабочее время (плюс 2-3 часовых пояса).
Железку покупать будет федеральный центр. От нас требуется более- менее обоснованное и не фантастическое предложение варианта реализации.
Такой ещё вопрос - что лучше для оракла - Xeon или Opteron?
В настоящее время обслуживаем БД порядка 600Гб, сервер многопроцессорный Opteron с 64Gib оперативки. В принципе, устраивает. Но винды.
С какой скоростью в единицу времени будет увеличиваться база? Сколлько IOPS планируется? Какая скорость чтения будет? итд итп. У разработчиков системы должны быть требованя к аппаратной части, очень рекомендую вытрясти из них данные. Без этого никогда не угадаете с конфигурацией.
Не видел ни одной реалиации БД на AMD, но я много чего не видел.
Если говорить о стоимости, то стоимость железки затеряется в сравнении со стоимостью Оракла, поэтому экономией на железе вы ничего кроме проблем не наживете.
Выбор для оракла надо делать между Xeon и SPARC новыми.
Если документы финансовые, то идите прямой дорогой к интегратору, не рискуйте.
Обратитесь к профессионалам интеграторам, это будет проще, дешевле и быстрее т.к. всё равно Вы самостоятельно вряд ли сможете так настроить аппаратную, программную часть и сам оракл, чтобы он хорошо держал высокие нагрузки, не падал и вообще не отсвечивал в предупреждениях системы мониторинга.
Опять же, много всяких подводных камней в HCL листах, а те же Dell. HP, IBM уже явно и не один десяток раз решали такие проблемы, поэтому готовые решения таких маститых монстров явно учтут и Ваши требования и те требования, о которым Вы можете и не знать на данный момент.
Поддерживаю, считаю что блэйд - совсем не то, что вам нужно. Вам нужно 1-2 мощных сервера и нормальную СХД. Любой системный интегратор вам быстренько составит ТКП под такую задачу. Определитесь только, какая ОС у вас будет - если Linux, то брать SPARC нет смысла.
1. Так-же не забывайте 6 RHEL не проходит по матрице совместимости с Oracle 11gR2
2. СХД лучше брать внешнее с поддержкой FC.
3. Сервера надо брать с оглядкой на ПО, для поддержки несколько БД
Я спросил в надежде получить от опытных людей советы и хинты. Так сказать, направление. От начальства пришла директива - подобрать конфиг HP BladeSystem c7000 Enclosure, подходящий для нашей задачи. Я понял, что этот девайс подходит слобовато. Так что, по итогу, что поставит федеральный центр, на том и будем работать. Или мучиться. Всем спасибо за (со)участие!
Позволю себе немного пофантазировать. Если уж никуда от блэйдов не деться, возможно стоит попробовать поднять RAC со всеми активными нодами. Плюс в том, что между блэйдами проще организовать быстрый интерконнект. Основная проблема в этом случае - грамотно спроектировать БД, чтобы по минимуму использовать интерконнект между нодами кластера. Ну и конечно без СХД вам не обойтись.
Есть ли смысл в наше время в использование RAC? Раньше при 1 ядре в процессоре, смысл был был, сейчас не вижу, 4 opteron по 16 ядер, вряд ли просядут, а ФС, при больших обьемах почти 100% не выдержит. Опять же потери на межсерверном взаимодействии могут превысить выгрышь от использования процессоров нескольких серверов.
Если требуется 24х7, то либо создавать для каждой базы Standby, либо поднимать RAC. С RAC'ом, насколько я слышал (сам не реализовывал), бывает очень много странных танцев с бубном, но зато вы получите балансировку нагрузки + устойчивость к отказам (если приложение сможет работать с RAC, оперативно переключаясь на другую ноду).
По поводу хранения - если у вас не High-end СХД с хорошими вычислительными мощностями, то лучше собирайте 1+0; если случится авария на 5 или 6, то велик риск смерти еще одного диска в группе, пока на Hot spare будут восстанавливаться данные; скорее всего, 600 Gb винчестеры у вас SATA и около 7200 rpm, так что они будут очень медленные.
В любом случае, бэкапы стоит продумать, хотя бы редкие; даже имея хорошую СХД и RAID большой избыточности, вы не застрахованы от смерти контроллера.
Всё упирается в объём данных. Сотни терабайт бэкапить на любые носители и по любой "проволоке" - геморрой :( Да и время восстановления делает схему с бэкапами настолько непригодной для использования, что я сомневаюсь в её нужности...
Средний
