Мы находимся на стадии планирования настройки нашей производственной среды Oracle 10gR2. Наш бюджет дает нам возможность купить 2 лицензии на процессор Oracle DB Standard Edition. У нас минимальный опыт работы с Oracle, поэтому я полагаюсь на всех, кто его использовал. Мы пытаемся решить, следует ли устанавливать один двухъядерный четырехъядерный блок или два отдельных четырехъядерных блока в конфигурации RAC.
Сейчас наша БД составляет около 60 ГБ, а на пике у нас будет до 150 одновременных пользователей. Большая часть больших операций выполняется с помощью пакетной обработки в ночное время.
Моя интуиция подсказывает мне, что наличие двух блоков в конфигурации RAC не может быть плохой вещью, потому что она обеспечивает настоящее аппаратное решение для аварийного переключения. БД хранится в общем LUN в сети SAN через iSCSI. Кроме того, если нам когда-либо понадобится добавить емкость, у нас уже есть блоки, которые можно обновить с помощью дополнительных процедур (я предполагаю, что с нулевым временем простоя, поскольку он настроен в конфигурации RAC), если мы добавим дополнительные лицензии или ОЗУ.
Есть ли у RAC штрафы к производительности? Это добавит дополнительную задержку? Есть ли какое-то реальное преимущество в двухпроцессорных системах, работающих на этих системах? Если мы построим блоки Oracle со специальным оборудованием: аппаратными картами iSCSI, сетевыми интерфейсами TOE, будут ли эти блоки прочными? Мы выполняем развертывание на 64-битной Windows.
Так что бы ты сделал? Одна или две коробки?
По возможности делайте это простым. Один ящик лучше многих для большинства приложений баз данных, если у вас нет особых причин, таких как производительность.
Аппаратный сбой с гораздо меньшей вероятностью приведет к простою, чем поломка из-за ошибки конфигурации. Более простая конфигурация обычно окупается за счет меньшего количества режимов отказа. Вы можете обнаружить, что на практике получаете более надежную систему с одним сервером и простой реплицированной базой данных на резервной машине.
Не стремитесь к более жесткому SLA, чем вам действительно нужно, и не создавайте систему с дополнительной сложностью для достижения SLA, которая не поддерживается всеми аспектами программного обеспечения, операций и оборудования.
Немного другой взгляд на надежность «пяти девяток».
Несомненно, ваш поставщик предоставит впечатляющие статистические данные о надежности своего продукта. В качестве контраргумента, вот девятка, связывающая различные уровни SLA с тем, что действительно необходимо для их достижения на практике:
Две девятки (99%) соответствуют 24-часовому периоду аварийного восстановления и могут иметь отношение к таким приложениям, как системы хранилищ данных, в которых система не поддерживает непосредственно операционные процессы. Такой уровень обслуживания достигается за счет восстановления системы из резервных копий.
Три девятки (99,9%) примерно равны 4-часовому периоду аварийного восстановления, и это действительно все, что нужно для большинства бизнес-приложений. Этот тип стратегии аварийного восстановления может быть реализован с помощью простой репликации доставки журналов и резервного сервера. Часто простота этого типа архитектуры означает, что в ней относительно мало режимов отказа, основанных на конфигурации, и на практике достигается значительно лучшая надежность. Существует множество примеров двухуровневых приложений 4GL, обеспечивающих непрерывную безотказную работу в течение месяцев или лет с помощью этого типа конфигурации.
Четыре девятки (99,99%) можно рассматривать как окно аварийного восстановления продолжительностью в несколько минут, и для них требуется архитектура горячего резервирования или горячего аварийного переключения. Достижение такого типа SLA на практике довольно сложно и обычно требует программного обеспечения, разработанного для этого. По иронии судьбы, дополнительная сложность кластерных многоуровневых архитектур открывает гораздо более широкую поверхность режимов отказа из-за неправильной конфигурации или промахов в управлении изменениями.
Следует отметить, что ошибки конфигурации и плохое управление изменениями являются основными причинами незапланированного простоя в работе центра обработки данных и с гораздо большей вероятностью могут вызвать незапланированный сбой, чем отказ оборудования на сервере.
Пять девяток (99,999%) требуют не более нескольких секунд внепланового простоя каждый год. Этот тип SLA помещает вас в сферу специализированного оборудования и программного обеспечения, созданного для обеспечения отказоустойчивости. Реализация этого типа SLA стоит дорого, требует специальной платформы, такой как мэйнфрейм, и людей со специальными навыками, которых у большинства компаний нет.
Большинство людей, утверждающих, что 99,999% SLA полны дерьма, q.v. Microsoft, Accenture и Лондонская фондовая биржа.
Я бы внимательно рассмотрел две вещи:
1) Поддержка 10gR2 уже начинает падать со скалы обслуживания. Примерно через год получение исправлений станет ОЧЕНЬ дорого, и Oracle уже заявила, что последние общедоступные исправления будут выпущены летом 2010 года. Есть ли причина, по которой вы не используете версию 11 при создании нового сервера?
2) RAC / Data Guard на самом деле довольно болезненно настраивать и поддерживать. Мало того, что для этого требуются лицензии Enterprise (намного дороже, чем стандартная лицензия), ваша серверная ОС также должна иметь версию Enterprise и быть настроена в кластере Windows.
Лично, если вы можете допустить возможность короткого периода простоя / потенциальную потерю данных, вам будет гораздо лучше с одним ящиком, в идеале имея «резервный» сервер, который можно было бы развернуть. Это всего лишь мои мнения, и я уверен, что их можно оспаривать, но на самом деле БД на 60 ГБ со 150 пиковыми пользователями уже не так уж велика. Двухъядерный четырехъядерный блок, вероятно, будет масштабироваться лучше, чем конфигурация RAC, конечно, если вы поместите вдвое больший объем ОЗУ в один блок.
Если проблема в деньгах, я настоятельно рекомендую другое решение СУБД.
RAC и DG очень сложно настроить и поддерживать, как указано. Вам действительно нужен опыт, чтобы справиться с этим. Желательно, чтобы вам потребовались SCAN, VIP, HB и HBA.
Кроме того, я настоятельно рекомендую держаться подальше от Windows для Oracle.
Данные в SAN также должны быть RDM, а не хранилищем данных.