Сравнение SPARC и x86 для сервера базы данных : Железо

Споры о том, что лучше SPARC или x86 возникают достаточно часто, поэтому решил сформулировать для себя некоторые мысли и записать их. Речь идет исключительно о моих выводах, базирующихся на моем же опыте, если я в чем-то неправ - прошу поправить.




Для начала: я не являюсь специалистом по железу и процессорам в частности, но, в силу профессии постоянно имею с ними дело, в том числе с достаточно большим количеством SPARC, пусть даже не топового уровня (например, М4000, М5000, Т4).

Допускаю, что я или окружение просто не умеют готовить эти машинки, однако в силу большой выборки могу предположить, что их умеют готовить слишком немногие люди, которые на моем пути не попадались вообще, а потому, скорее всего, не попадутся и вам.

На моей истории был один случай переезда с M5000 на Xeon (Linux) с полным восторгом по результату. Обратно не переезжали никогда.

Я не буду останавливаться на том, насколько не по человечески (не для людей) сделана Solaris по сравнению с Linux. Речь идет просто о сравнении нескольких серверов как на базе SPARC, так и Xeon, достоинствах и недостатках этих решений, как если смотреть со стороны администратора, использующего их, а не настраивающего систему. И, да, речь идет исключительно о нагрузке базами данных.

Менеджеры Oracle по вполне понятным причинам очень любят говорить о преимуществах решений, однако, при сравнении используют исключительно топовые решения, например S7, говоря о производительности процессора, а не ядра. В этом их сильная сторона, действительно, поскольку в одном процессоре SPARC поддерживается значительно больше потоков (напрямую сравнить процессоры затруднительно в силу терминологии и архитектуры). Однако, в силу конской цены на SPARC и железа с ним связанного, это преимущество совсем не очевидное, даже с учетом того, что Oracle по количеству процессоров SPARC лицензирует RDBMS дешевле. Иными словами, вместо того же m4000 можно купить ну очень крутой x86. Варианты с Itanium и прочими здесь рассматривать не будем, как и вообще их нет смысла рассматривать.

Снова о производительности. Огромное число потоков, которыми обладает SPARC, увы, в большинстве случаев становится ненужным, поскольку чуть ли не большинство операций достаточно просты, чтобы их можно было распараллелить. Большинство использующих Oracle RDBMS, не используют шифрование или хеширование, в чем сильны SPARC своей аппаратной поддержкой. Опция шифрования в базе достаточно дорогая. В итоге Xeon по производительности одного потока (ядра) вырывается далеко вперед, оставляя SPARC нюхать пыль высохшей термопасты. При количестве до 200 активных сессий, как были у меня базы, SPARC грустно курил в стороне. Совокупная производительность сервера x86, купленного за значительно меньшие деньги, чем m4000, не оставляла никаких шансов соляркиному железу. База в терабайт в несколько потоков сжималась в бекап на "Царе пингвинов", как окрестил Linux x86 мой шеф, за 10 минут. m4000 такое и не снилось.

Очень большая проблема возникла при планировании тестовой среды. Иными словами, никто никого не спрашивал, передо мной поставили два сервера и сказали, что один для промышленной эксплуатации, а второй - тестовый и резервный. Ха. Уже через полгода резервный был забит базами, а требовались еще и еще. И что делать? Никаких вариантов нет "использовать тот сервер временно". SPARC'а в конторе всего два, их нигде не сэмулируешь, из воздуха не соберешь, а переносить на х86 - глупо, во-первых скрипт достаточно сложный со всеми этими индейцами (endian), а во-вторых, на другой платформе и баги другие. Смысл-то так тестировать? При переезде на x86 вообще не ломали голову, только с местом на хранилках проблемы возникали, но это, понятно, к платформе никак не относилось. Зато никаких тебе "наперстков" с базой в несколько терабайт. Очень существенная причина не выбирать SPARC, если у вас их не пара десятков.

Отсюда же растет проблема скорости замены и ремонтопригодности. В силу ценника на железо и сравнительной его нераспространенности, лечить машинку на SPARC вы будете достаточно долго. Понятно, что есть сроки по саппорту, но попасть можно и достаточно просто. Сроки замены железки, которых ворох по всему городу, значительно меньше сроков доставки из другого города, например.

На тему сверхнадежности SPARC-железок, которую так пропагандируют. Смотря с чем сравнивать. Если с HP-UX железкой на Itanium (тИтанике), которая как будто вся развалилась сразу после покупки (заменили все, от блока питания до памяти), то да, очень надежная. За 4 года вышла из строя одна планка памяти, как я помню. Просто где-то какой-то контроль заверещал, что проблемы, планку выковырнули, подрезали памяти базе, после замены базе памяти разрешили скушать больше. По питанию было что-то... Чего-то экстраординарного не заметил. К слову, на x86 за два года большей нагрузки проблем не было вообще.

"Порог вхождения" для персонала - немаловажный довод. Если Linux-железки видел каждый админ, то с Solaris дружба совсем не у многих. Причем, даже у тех, кто обязан эти железки поддерживать. Настроили не так, оценили произошедшее не так - как результат большое время простоя критичного сервиса даже при наличии саппорта.

Выводы: SPARC - не икона и в большинстве случаев не нужен. Эта платформа не для нищебродов и если собрались увеличить капитализацию своей фирмы за счет таких железок, планируйте затраты минимум в двукратном размере от того, что насчитаете с первого захода. Глупо покупать меньше десятка SPARC-серверов сразу. Если не шифруете свои базы - смело берите x86. Будет дешевле и лучше работать. Особенно, в пределах 500 активных пользователей.