В последнее время часто приходится отвечать на вопрос, почему при конструировании высокопроизводительных систем, на которых будет работать ПО Oracle, мы предлагаем более дорогие сервера на базе SPARC T4... Почему, скажем, не наши же x86 машины? Ведь СУБД и сервера приложений Oracle портированы на кучу платформ... Почему мы предлагаем именно Solaris и именно на SPARC T4?
Ответ до неприличия прост - потому что отношение производительности к стоимости получающейся инженерной системы получается при этом наилучшим. Рецепт этого решения подготовлен разработчиками Sun Microsystems / Oracle и маркетологами; первые подготовили отличные HW & SW, вторые - установили выгодные правила лицензирования.
Для начала посмотрим на производительность; интересно, как SPARC T4 смотрится на фоне конкурентов... Предлагаю пройти на страницу TPC Benchmark™H (TPC-H) и открыть результаты производительности трехтеррабайтной некластеризованной системы.
Итак, что мы видим? Четырехпроцессорный Oracle SPARC T4-4 с 32 ядрами демонстрирует 205792 "попугаев" с Oracle DB 11gR2. Затем идут сервера IBM на Power7 и Power6 (соответственно 8/32-192001 и 16/64-156537) с Sybase IQ, между которыми вклинивается сервер HP ProLiant DL980 G7 Intel Xeon (8/64-162601) с MS SQL Server 2008 R2 EE. Т.е. SPARC T4-4 оказывается на четверть более производительным, чем ProLiant DL980 и обходит раскрученные сервера IBM на Power!
В тесте террабайтной системы решение на процессорах Intel от HP смотрится получше, но в том сравнении мы не использовали преимущества Oracle Solaris 11. В любом случае - сервера на SPARC'ах показывают очень достойные результаты по производительности! А чтобы получить более жизненные цифры по стоимости транзакции, надо привести всех к общему знаменателю, пролицензировав на всех системах один и тот же набор ПО...
Возвращаемся к теме блога :-) Допустим, заказчик хочет реализовать высокопроизводительную систему разделения доступа на базе Oracle Access Management Suite. WebLogic, Identity Manager, BI Publisher и несколько других компонентов он получает в рамках ограниченных лицензий; но, как минимум, заказчику потребуется СУБД Oracle в качестве хранилища OIM и политик. Опционально может понадобиться LDAP-каталог; добавим Oracle Directory Services, хотя среди сертифицированных решений числятся еще и Microsoft Active Directory 2003/2008 или Novell eDirectory 8.8.
Займемся подсчетом рекомендованной стоимости ПО по публичному прайс-листу. Выбранные решения лицензируются по процессорам (Access Management Suite Plus стоит $180000, Directory Services Plus - $50000, Oracle Database Standard Edition - $17500), определение которых можно найти в конце документа. Там мы встретим понятие Oracle Processor Core Factor; это - один из инструментов маркетологов, значение которого для разных процессоров можно посмотреть в таблице на страничке OLSA.
Наиболее затратно лицензировать ПО Oracle на современных RISC-серверах IBM, к процессорам которых применяется core factor "1.0" (no comments)... Вначале кажется, что SPARC T4 и современные Intel Xeon процессоры находятся в равной позиции, поскольку и там, и там работает один и тот же core factor "0.5"; но это верно лишь для ситуации, когда мы хотим под одну лицензию задействовать все ядра процессора(ов). Однако чаще всего на мощных серверах одновременно выполняются несколько разных задач, и тут в действие вступает второй инструмент маркетологов - правила зонирования (сегментирования/секционирования)!
Сравним, как они действуют в отношении восьмиядерных процессоров SPARC T4 и Intel Xeon X7560 (аналогично - для процессоров Intel Xeon Series 56XX, 65XX, 75XX, Series E7-28XX, E7-48XX, E7-88XX). Открываем файл «Partitioning» и видим, что в отношении SPARC T4 можно применять высокоэффективную технологию Solaris Containers, а в отношении x86-серверов - только жесткое зонирование на уровне настроек Oracle VM Server. Т.е., для того, чтобы на x86-сервере выделить по одной процессорной лицензии для каждого выбранного выше продукта, надо установить Oracle VM Server (гипервизор на базе Xen) и сконфигурировать в нем 3 или 4 домена под гостевые системы. В настройках надо указать, что каждый использует только 2 ядра, а затем - проинсталлировать в эти домены гостевые операционки и только потом - программные решения!
Я думаю, любому мало-мальски грамотному техническому специалисту будет ясно, насколько неэффективно при этом будут расходоваться аппаратные ресурсы... Сравните это с вариантом, использующим 4 двухядерных контейнера Solaris; в три мы устанавливаем продукты, требующие лицензирования, в четвертый - OIM и получаем оптимально загруженную систему! Никаких лишних гостевых OS! Добавьте к этому обязательную сертификацию всего решения вендором, единую поддержку, и аргументы покажутся вам еще более весомыми. Удачного вам выбора!
Комментариев нет:
Отправить комментарий