SPARC vs Intel

Posted on February 1st, 2010

Иногда случается, что к людям, которые админят солярис приходят люди, которые админят линукс и ехидно улыбаясь, спрашивают, “ну и чем они лучше эти ваши спарки?”. Особо продвинутые начинают демагогию насчет регистровых окон и у кого TLB больше, а те, кто попроще, просто говорят что спарк “энтерпрайзнее” и соляра на стоголовом боксе разорвет линух просто потому, что лучше масштабируется. Вопросы о sparc vs intel стали особенно актуальны сегодня, а во времена расцвета сана и огромных многопроцессорых машин вопрос был не особо актуален, т.к. тогда просто не было эквивалентных по мощности серверов интел. Итак, недавно в одном из сановских блогов появилась статья по теме, ниже приводится её перевод. Ссылка на первоисточник SPARC vs Intel.

По мере того, как процессоры интел становятся все мощнее (больше ядер (реальных процессоров со своими собственными ресурсами), появились технологии SMT – Simultaneous Multi Threading, где имеется более одного виртуального процессора на каждое ядро, содержащего т.н. потоки, разделяющие ресурсы процессора (кэш и конвейер), встроенный контроллер памяти (архитектура Nehalem), 3 канала памяти DDR3 на сокет (увеличивает пропускную способность при доступе к памяти), масштабируемость до 2х сокетов (скоро будет до 4х), возникает резонный вопрос, имеет ли смысл продолжать использовать
SPARC процессоры для бизнес приложений?

Здесь озвучены некоторые идеи, которые стоит принять во внимание, и, хотя вряд ли они будут иметь один и тот же вес для всех на отдельно взятом предприятии, все же попробуем…

Как большинство из вас уже знают, стратегия разработки Интел – Tick-Tock, в соответствии с которой в течении 2х лет появляется технология разработки с уменьшением нм-процесса, производная от уже существующей, такой как Core (например от 45 до 32нм), что приводит, например у уменьшению энергопотребления, а затем разрабатывается новая микро-архитектура (как, например, Nehalem). Так, в течении 2х лет вы получаете новый процессор для платформы бизнес-приложений. Вау! Отлично. Кроме того, в мозгу большинства маячит 2 идеи:
1. машины Intel дешевле, чем SPARC.
2. машины Intel быстрее, чем SPARC.

Факты об Intel 55xx.
1. 2 процессора интел одной архитектуры, но с разными частотами не могут сосуществовать в рамках одной платформы. (нельзя смешивать частоты в пределах одного поколения процессоров, см. п.2 стр. 26 Intel® Xeon® Processor 5500 Series Datasheet, Volume 1)
2. каждый новый процессор интел несовместим с процессором предыдущего поколения.
3. емкость памяти системы должна (начиная с Nehalem) расти с числом процессоров, т.к. контроллер памяти находится на процессоре.
4. Время жизни процессора Интел меньше, чем спарка. Попробуйте проапгрейдить сервер, поддерживающий Intel Xeon 5200, анонсированный менее 2х лет назад), поэтому система интел должна быть дешевле в момент покупки, т.к. вам придется её полностью заменить, чтоб удовлетворить потребности бизнеса. “вы услышите: мы разработаем новый модуль ПО в следующем году,
поэтому нам нужно будет больше ядер и вдвое больше памяти в последующие 6 месяцев”.
5. процессор интел на 2х процессорной системе отличается от оной на 4 (или уже скоро на процессорной (5500 и 74xx/75xx соответственно). Попробуйте сделать VMotion из 2х процессорной системы в 4х процессорную… и процессоры отличаются не только в набивке (частота шины/число линков QPi) но и в цене (сравните 2.66 4х ядерный процессор серии 5×00 с серией 7×00)
6. Если Nehalem поддерживает различные частоты и настолько экономичен по потреблению энергии, то зачем делать столько вариантов частота/можность? (см. стр. 14 INTEL roadmap), я бы логически рассудил, что низкая частота, средняя частота и высокая частота должна бы покрыть все нужды бизнеса?
7. Что бы вам не говорили консультанты о TCO, это не только цена сервера, это цена, которую вы платите за производительность, плюс цена за обслуживание того, что получится в результате (человекочасы на обслуживание, интеграция с существующей системой, контроль, обновление, цена электроэнергии и охлаждения). И тогда, когда вы сравните производительности, выбирайте ту, которая больше подходит под ваше приложение.

Факты о SPARC64:
1. 2 похожих SPARC64 процессора с различными частотами могут работать вместе (смешивание частот в рамках одного поколения разрешено)
2. новое поколение SPARC64 совместимо с предыдущим (смешивание поколений разрешено)
3. емкость памяти не привязана к числу процессоров (SPARC64) т.к. контроллер памяти не встроен в процессор. Можно иметь половинное число процессоров при полном объеме памяти.
4. продолжительность жизни процессора SPARC64 больше, чем у Intel, кроме того, у спарков есть возможности RAS, ещё не реализованные в процесорах интел (read chapter 5 of this paper).
5. ядро Solaris на процессорах SPARC64 VII работает без модификаций на 4 и 8 процессорных системах и используя зоны вы можете даже переместить зону с процессора SPARC VI на SPARCVII или даже запустить её на процессорном сете, состоящем из процессоров разных поколений.

Выводы:
1. для небольших систем (2/4 процессора) платформы интел идеальны, но они должны быть куплены с полной набивкой, чтоб избежать апгрейдов и проблем с вертикальной масштабированием из-за того, что процессоры /память должны работать более 2х лет. Получается, что горизонтальное масштабирование на уровне приложения выходит дешевле вертикального масштабирования на уровне железа,однако если вы учтете стоимость лицензий для реализации решений высокой доступности + человекоресуры для управления всемими этими системами (установка, патчи, мониторинг, лицензирование + цена владения идентичной конфигурацией) в конец концов все закончится множеством систем, которые через несколько лет будет сложно сопровождать (если вы регулярно не обновляете железо и софт).
2. для систем, где горизонтальное масштабировение, приводящее к большому количество систем, которые нужно патчевать, обновлять и мониторить) не подходит, и нам нужна система более чем с 8 процессорами, SPARC – (Scalable Processor Architecture) – идеальное решение. не только на уровне железа, а также и на уровне ядра ОС (Solaris), которое знает, как правильно разбираться с потоками в системах, где есть и SPARCVI и SPARCVII.
3. Системы интел не совсем хорошо вписываются в мир виртуализации (смесь частоты/поколения), где гипервизор должны быть на аппаратном уровне или по крайней мере там, где возможно разбиение на аппаратные разделы и где достаточное количество тредов должны обрабатывать определенное число прерываний (сетевой траффик и ввод-вывод) в системах, где одновременно запущено большое количество виртуальных машин.
4. быстрый процессор это конечно хорошо, но т.к. доступ к памяти всё ещё тормозит, единственный способ увеличить эффективность работы процессора (занять его чем-нибудь, пока он ждет ответа из памяти) это виртуализировать его, создать конкурирующие виртуальные процессоры (т.н. потоки) выполняемые на одном ядре. Примером является SPARC CMT, который в 2005г. выполнял 4 потока на одном ядре (SPARC T1), давая 8-ядерному процессору процессору достаточно ресурсов для оброботки большого количества запросов ввода-вывода. Как вы уже наверное заметили, даже интел идет в том же направлении, где ядро Nehalem может выполнять 2 SMT потока. Т.к. число потоков будет только расти, мы увидим некоторое уменьшение тактовых частот и компромисные значения размеров внутренних кешей. Пример: X5272 @3.4 GHz, 2 cores 6MB of L2, no L3, 80W становится X5492 @3.4 GHz, 4 cores, 12MB of L2, but 150W. Теперь, Nehalem это новая архитектура, появился кеш L3, общий для всех ядер, а L2 уменьшен до 256к на ядро. Таким образом W5580 @3.2 GHz имеет 4 ядра, 1MB of L2, 8MB of L3, 4 cores, 8 threads, 130W. То есть добавление 2 тредов на ядро в нехалем приводит к введению L3, уменьшению L2 и уменьшению тактовой частоты с 3.2 до 3.4 ггц. Посмотрим, что произойдет, когда интел сделает 4 треда на ядро.

Имейте ввиду.
Итак, прежде чем сделать свой выбор в пользу спарка или интела, подумайте вот о чем.
1. потребности бизнеса (сегодня и завтра)
2. бюджет (стоимость приобретения и стоимость владения)
3. развитие (да, нагрузка системы и приложения растут)
4. трехлетняя стратегия. делайте больше меньшими усилиями (виртуализация), будьте более гибким, используйте то, что уже есть.
выбирайте правильную архитектуру, которая позволяет достичь этого с наименьшими затратами.
5. системная архитектура: нет универсальной архитектуры процессора, котороая бы могла удовлетворить нагрузки обработки данных (последовательная производительность), нагрузки обработки сетевых запросов(многопоточность), которые бы линейно масштабировались по количеству процессоров, поддерживали бы виртуализацию, гарантировали бы двоичную совместимость приложениями и в том же самое время были бы дешевы… вы должны выбирать процессор исходя из особенностей конкретного приложения.

Мои советы:
- виртуализируйте там, где это возможно
- используйте интел там, где нет выбора из за проблем с производтельностью.
- держите как можно меньше версия ядра (солярис контейнеры/лдомы)
- держите как можно меньшее кол-во слоев ПО, чтоб делать меньше апгрейдов софта при необходимости делать апгрейд одного из слоев.
- предпочитайте гипервизор самого нижнего уровня (железячный) если вам нужна виртуализация, это уменьшит накладные расходы и упростит систему.
- думайте о том, чтоб иметь системы высокой доступности, если нет, то виртуализация поможет вам достичь разумной-доступности.

Filed under Russian | No Comments »