На Новый Год принято дарить подарки, а меня попросили ответить на вечный вопрос – что же лучше, AIX или Linux? Этот вечный вопрос задают с завидной регулярностью, но в разных ипостасях, в т.ч. зачем мне покупать дорогой сервер Power, когда я могу купить дешевый x86 и получить сравнимую производительность? Зачем нужен Linux на серверах Power? Или наоборот – зачем платить за лицензию на AIX, когда можно поставить бесплатный Linux? В свое время мне даже рассказывали историю об одном заказчике, купившем сервера pSeries, чтобы на них поставить Gentoo Linux, но через год докупившего лицензии на AIX.
«Лучше» - категория субъективная, поэтому отвечая на любой из этих вопросов, мы переходим зачастую в область религиозных войн и бесконечного флейма. Поэтому, как всегда, все ниженаписанное отражает лишь точку зрения автора, т.е. мою. Она не является и не может являться единственно верной – у каждого человека своя правда.

Моя правда заключается в одном простом постулате – все зависит от тех задач, которые стоят перед Вами и от тех ресурсов, которыми Вы располагаете для решения этих задач. Если Вам нужно поднять DNS-сервер или Apache c MySQL и PHP для небольшого форума или вики, то зачем Вам тратить десятки или сотни тысяч долларов на покупку дорогущего сервера с AIX‘ом? А может быть совсем наоборот – у Вас стоит куча серверов IBM и нужно поднять тот же самый DNS или LAMP? Тогда, чем покупать еще один x86 сервер, может быть быстрее и проще нарезать один маленький LPAR и поcтавить на него AIX?

Выбор платформы должен начинаться еще задолго до требования бизнеса о внедрении очередного новомодного приложения. И первым шагом в этом выборе должен стать анализ существующей инфраструктуры. Что есть у нас в наличии? И каким образом мы предполагаем развивать это дальше? Какие финансы готово инвестировать руководство в развитие ИТ? И есть ли стратегия развития этого самого ИТ?

Каждый раз, когда я писал обоснование о закупке очередного сервера на много сотен тысяч американских долларов, я вспоминал, как когда-то давным-давно пытался обосновать закупку SPARC‘ового сервера стоимостью ок. 15 тысяч USD. Эта затея провалилась. Я был уверен в крутизне этого самого сервера и его необходимости для дальнейшего развития бизнеса организации. Но я не смог этого доказать своему руководству, поскольку это были слишком большие расходы для той организации. Люди, которые дают деньги на развитие ИТ, мыслят (или должны мыслить) в категории возврата от вложенных инвестиций и если нет ясного и четкого плана развития бизнеса, и ИТ как составляющей этого бизнеса, то никогда в жизни бизнес-подразделение не поймет, почему оно должно зарабатывать деньги, чтобы ИТ их потом тратило.

Если весь парк серверов организации построен из принципа использования как можно более дешевых серверов, то какой смысл этой организации использовать сервера дорогостоящие? Есть ли смысл Google’у использовать для поиска AIX? С моей точки зрения – никакого. Веб-приложения Google’а изначально написаны для горизонтального масштабирования, выход из строя одиночного сервера никак не влияет на функционал приложений. Может ли Google извлечь какую-либо пользу из использования функций RAS серверов IBM или от использования систем виртуализации? Очень сомнительно. Функции RAS Google‘у вообще не очень сильно нужны, поскольку обеспечение надежности вынесено в код приложения, а виртуализация в масштабах Google‘а может только ухудшить надежность. Предположим, Google купился на обещания IBM и вместо 1000 своих Linux-боксов поставил один большой и толстый мейнфрейм от IBM. И вот этот мейнфрейм сломался. Опс – и минус тысяча серверов. Я, конечно, понимаю, что в масштабах Google‘а тысяча серверов – это всего лишь 1/200 или 1/300 от их общего количества, но это в любом случае больше, чем 1 сервер. Я также прекрасно знаю, что у подобных компаний, как Google, могут выходить из строя целиком датацентры, содержащие не одну тысячу серверов, и компания продолжит работать, а пользователи с высокой долей вероятности этого даже не заметят. Но стоит ли овчинка выделки?

Или другой вариант – все ИТ компании состоит из одного администратора, совмещающего в себе функции и хелпдеска, и программиста, и веб-мастера, и т.д. А весь парк серверов – это десяток компьютеров, собранных на коленке из запчастей, купленных на ebay. Какая задача может стать перед этой организацией, чтобы ей потребовался сервер Power? Лично мне это представить очень сложно. Насколько должен вырасти оборот компании (и ее прибыль), чтобы руководство задумалось о необходимости закупки дорогущего сервера?

А третий пример – это пример банка, в котором я работал. Когда я пришел туда, основной платформой был Wintel, около 100 серверов под Windows, две AS/400 и около 5 серверов Linux. Нужен ли был AIX такому банку? Вероятно, нет. По крайней мере на тот момент я был в этом уверен. Но руководство ставило планы развития бизнеса в России – сколько должно быть привлечено новых клиентов, насколько должен увеличиться оборот (и прибыль) организации. Под эти планы необходимо было открывать много новых отделений и нанимать много новых сотрудников. Руководство ИТ оказалось на тот момент на перепутье – продолжить развиваться по старому пути или выбрать новый. Старый путь – это создание «самопальных» приложений силами In-House Development для платформы Wintel. Новый – закупка готовых приложений и их внедрение. Старый путь предполагал на начальном этапе увеличение количества разработчиков, а затем – их удержание, кроме этого увеличение количества серверов Wintel, увеличение количества администраторов, усложнение инфраструктуры, и при этом – непонятные сроки с вводом в эксплуатацию нового функционала, который требовался банку, ибо разработчики люди креативные, и им требуется много времени, чтобы довести все до совершенства.

Второй путь – покупка готовых приложений – не мог удовлетворить все требования бизнеса на 100%, но зато позволял гораздо быстрее вывести на рынок новые продукты и обеспечить выполнение планов банка. Поэтому был выбран именно второй путь. Конечно, забегая вперед, я могу сказать, что первый блин, как полагается, был комом, а шишек мы набили очень много. И когда руководство решило, что банк не является ИТ-компанией, и мы будем покупать готовые приложения, а не разрабатывать свои, встал вопрос о выборе платформы. При наличии развитой Wintel-инфраструктуры (а она в банке была и остается лучшей из всех, что я видел) напрашивается очевидный выбор – надо разворачивать все новые приложения также на Wintel, но на мое админское счастье было принято другое решение.

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

И переходим ко второму вопросу при выборе A vs B – требования поставщика приложения. С нашей стороны бизнес требует, чтобы была обеспечена работа определенного количества пользователей и время отклика приложения. Здесь самый важный документ – это наличие четких технических требований к внедряемому продукту. Естественно, бизнес никогда в жизни не сможет Вам ответить на Ваши вопросы. Он не знает, что такое время отклика. Он не знает, что такое загрузка процессора или объем памяти, и сколько IOPS‘ов должна обеспечивать система хранения. А уж объяснить, почему пропускной способностью не исчерпываются все характеристики канала, вообще невозможно. По идее для этого должны в штате существовать бизнес-аналитики. Или за штатом – в качестве временной наемной силы. Только зачастую существуют они лишь в воображении, либо их качество оставляет желать лучшего, также как и качество большинства проектных менеджеров.

Для того, чтобы технические требования все-таки появились и были хоть как-то приближены к реальности, требуется достаточно долгая и кропотливая работа технических специалистов (т.е. нас с вами) вместе с бизнес-заказчиком и поставщиком приложения. При этом обычно все три стороны разговаривают на разных языках – абсолютно разных. Вы можете говорить на одном и том же русском языке, только вот понимание от этого не увеличится. При этом бизнесу все равно, что творится в Вашей инфраструктуре, – главное как можно быстрее внедрить приложение. Поставщику все равно, как будет выглядить инфраструктура, - как главное продать приложение, а желательно еще и дополнительные услуги. И единственный человек, кого заботит Ваша инфраструктура – это Вы. По совместительству, Вы же будете ответственными за все ошибки в развитии инфраструктуры. Если приложение не будет внедрено в срок, либо после внедрения не будет работать, то виноваты будете Вы, а не бизнес, который ставил нереальные задачи, и не поставщик, который вообще понятия не имеет, что у Вас творится. Поэтому именно системному администратору приходится учить язык других подразделений – не для того, чтобы подстраиваться под них, а чтобы максимально эффективно развивать инфраструктуру. Кстати, спасибо Вам скорее всего не скажут, чтобы благодаря Вам уровень расходов на инфраструктуру остается ниже, чем он мог бы. Скорее наоборот – Вас обвинят в чрезмерном увеличении бюджета, а также во всех прочих грехах. Меня, например, пытались обвинить в получении взяток от некоторых из наших поставщиков.

Итак, поставщику все равно, какая будет у Вас инфраструктура. Он готов Вам продать свое решения и для Linux, и для Windows, и для AIX, и для Solaris, и для... Называйте любую операционную систему, скорее всего крупный поставщик поставляет свое ПО для этой системы. Бывают, конечно, исключения – например, Oracle не поставляет свою СУБД для AS/400. Но тем не менее, мы имеем широкий выбор, куда нам ставить Oracle. Первый вопрос – а что нам рекомендует сам поставщик? Все, например, знают, что тот же Oracle в первую очередь заботится о Linux и Solaris, а как следствие, видимо для запуска Oracle это будут приоритетные платформы. С другой стороны, Oracle (если рассматривать СУБД) – это всего лишь такое же инфраструктурное решение, как и операционная система, и никто никогда не покупает Oracle ради Oracle. Покупают какой-нибудь Oracle E-Business Suite, а для него используют Oracle. Или покупают SAP, а для него используют DB2. И говорить мы будет со специалистами по OEBS или SAP на тему рекомендованной платформы. А для того, чтобы им было легче что-то рекомендовать, мы должны предоставить им сведения, как бизнес-характера – количество пользователей, количество бизнес-операций, рабочее время, так и технические – наши знания о нашей инфраструктуре. По хорошему поставщик приложения должен провести сайзинг своего решения под наши требования и расписать нам, что под наши требования надо закупить железо, отвечающее следующим требованиям. В идеале эти требования должны быть выражены в каких-либо сравнимых единицах – RPE2, TPC-C, Spec и т.п. К сожалению, на практике это практически никогда не случается. Один из моих поставщиков в ответ на требование представить сайзинг своего решения для AIX и HP-UX представил сайзинг для ... Sun Solaris. И рекомендовал нам самим заниматься сравнением серверов Sun с серверами IBM и HP. Поскольку человек я простой и не люблю усложнять себе жизнь, то я напряг этим вопросом горячо уважаемых вендоров.

Получив рекомендации поставщика приложения, неплохо было бы вспомнить о нашей инфраструктуре и о том, насколько хорошо мы ее знаем. Варианты развития событий:
- рекомендация поставщика хорошо вписывается в существующую инфраструктуру;
- рекомендация поставщика требует доработки под нашу инфраструктуру;
- рекомендация поставщика не подходит под нашу инфраструктуру.

В первом случае все идеально и думать абсолютно ни о чем не надо. Мы соглашаемся с поставщиком приложения и вносим его рекомендации в конечный документ – Technical Requirements или Non-Functional Requirements. Не забудьте потребовать подписи под этим документом от поставщика и от бизнеса! Все дальнейшие проблемы с приложением, если они будут списываться на Вас, будете адресовать к этому документу и к тем требованиям, которые были Вам выставлены.

Во втором случае обычно тоже никаких проблем не возникает. Например, поставщик рекомендует Вам поставить приложение на блейды IBM JS43, а Ваша инфраструктура построена с использованием стоечных серверов IBM Power. Проблема решается перерасчетом rPerf одного в другое и Вы просто заменяете JS43 на, например, Power 550, после чего снова пытаетесь согласовать свое видение с поставщиком. Здесь поставщики делятся на два типа – тех, которые соглашаются с Вашими доводами, и тех, которые не соглашаются. Вторые обычно очень сильно боятся ответственности, сайзинг за них сделала лаборатория где-то далеко в Канаде, Филиппинах, ЮАР, Израиле или в какой-нибудь Бразилии, и они не могут своим волевым решением изменить его результаты. Поэтому они будут настаивать на включение в документацию их сайзинга, а Ваш сайзинг пойдет как пожелание заказчика. Но большинство нормальных поставщиков и их вменяемых специалистов соглашаются с сайзингом заказчика, если видят, что он не ухудшает производительности системы, и понимают причины, по которым заказчику пришлось изменить сайзинг. Чтобы избежать подобных ситуаций надо сразу же на этапе запроса сайзинга максимально четко описывать поставщику свою инфраструктуру – какие сервера, маршрузаторы, СХД являются для Вас приемлимыми, а какие Вы не будете использовать ни при каких условиях.

Самый тяжелый случай – это третий, когда рекомендация поставщика вообще не подходит под Вашу инфраструктуру. Например, вся Ваша инфраструктура построена на Linux/x86, а поставщик вообще не поддерживает Linux и рекомендует использовать AIX. Или Ваша инфраструктура построена на Windows, а поставщик утверждает, что для выполнения Ваших бизнес-требований Windows не подходит и надо использовать исключительно SuperDome и HP-UX. И тут выбор у Вас небольшой – Вы либо отказываетесь от поставщика и ищите другого, либо соглашаетесь с ним. В небольшой компании, где все друг друга знают и все легко и просто, можно также легко отказаться от поставщика приложения и выбрать нового. В большой компании, где бизнес требует именно это приложение, Вам скорее всего не удастся убедить совет директоров, почему из-за Вашего любимого Linux или Windows (или AIX) надо отказаться от выполнения бизнес-планов. Скорее совет директоров рекомендует директору ИТ сменить команду системных администраторов, чем прислушается к доводам о том, что Linux, Windows, AIX, ... – это круто!

Итог – выбор платформы, операционной системы, СУБД, СХД и всей прочей инфраструктуры зависит зачастую от внешних обстоятельств, а не от желания системного администратора. Системный администратор лишь обслуживает системы, которые ему доверили обслуживать. И чтобы это доверие оправдать, системный администратор должен досконально, во всех подробностях, знать свою инфраструктуру, а также сотрудничать с бизнесом, быть максимально открытым для бизнес-подразделений своей организации. Это позволит внедрять решения, которые требуются бизнесу для его развития, и при этом эффективно развивать ИТ инфраструктуру организации, минимизируя расходы на ее поддержание.

А теперь перейдем от лирики к физике. Есть организация с ИТ-подразделением. Бюджет ИТ на следующий год на закупку серверов составляет 100 000 долларов. В следующем году бизнес планирует внедрить два приложения. Приложение 1 – стандартное трехзвенное приложение, состоящие из БД размером ок. 100 ГБ и J2EE-приложения. Поскольку разработчик был очень хорошим и умным, то все написано максимально в соответствии со стандартами и портабельно. БД может быть развернута на любой СУБД - от MySQL до DB2 для z/OS. J2EE приложение тоже легко разворачивается на всем от Apache Tomcat до IBM WebSphere AS и BEA WebLogic. С приложением 2 уже хуже – там уже две БД, одна не очень большая, которая используется при работе большинством пользователей, размером ок 50 ГБ. В худшем случае вырастет до 100-150 ГБ, но это маловероятно. Во вторую БД скидываются данные каждый день и она используется в дальнейшем для построения отчетности. Ожидается, что через два года размер БД составит ок. 2 ТБ. Бизнес требует, чтобы информация все два года хранилась в БД для онлайн-доступа и не скидывалась на ленту. Приложение 2 имеет также J2EE часть, предназначенную для каждодневной работы большинства пользователей (их ожидается 200 человек), но кроме этого есть толстый клиент, с использованием которого строятся отчеты из второй БД. А также есть некое приложение, написанное на старом добром Си, которое и осуществляет весь процессинг, выполняя все те операции, ради которых бизнес и хочет купить это приложение. Перед Вами, как ответственным за инфраструктуру, стоит задача – нужно определиться, какие сервера закупать, какие использовать операционные системы, СУБД, сервера приложений, СХД и все остальное. В общем, Вы отвечаете целиком и полностью за инфраструктурную часть этого проекта.

Поскольку тема – AIX vs Linux, то я буду пробовать построить инфраструктуру на Linux и на AIX. Я не буду сознательно строить гетерогенную инфраструктуру, где есть и Linux, и AIX, поскольку будет нарушена «чистота» эксперимента.

Итак, вариант 1 – Linux.

Наш бизнес требует по возможности сократить расходы на капитальные вложения в инфраструктуру. Мы решаем, что самый правильный вариант в этом случае это Linux, т.к. сервера для Linux/x86 стоят дешево, администраторы – тоже не очень дорого. Для приложения 1 нам потребуются сервера БД, сервера для J2EE приложений и сервера для HTTP. Люблю я ставить Apache перед серверами приложений.

Поскольку размер БД не очень большой, то мы можем легко разместить всю БД на внутреннем сторедже. Для размещения БД в 100 ГБ нам потребуется лишь один диск в 146 ГБ. Для обеспечения надежности поставим 2й диск и сделаем RAID1. Поскольку от размера БД еще останется ок 46 ГБ, то мы можем легко использовать это место для размещения операционной системы и самой СУБД. Чтобы сэкономить будем использовать MySQL – бесплатно, никаких лицензионных отчислений и проблем. Для обеспечения надежности поставим второй сервер точно с такой же конфигурацией, а MySQL будет реплицировать данные с Master‘а на Slave.
Дальше переходим к серверам приложений. Туда мы поставим Apache Tomcat, поскольку он опять-таки бесплатный. Точно так же поставим в сервера по 2 диска, но на этот раз они нам большие не нужны. Подошли бы и диски по 18 ГБ, если бы они все еще продавались. Точно так же объединим их в зеркало, водрузим сверху Linux и Tomcat, а на Tomcat‘е развернем приложение.
Поскольку нам нужна какая-никакая надежность, то мы развернем рядом второй сервер с точно таким же Tomcat‘ом и точно таким же приложением. Настраивать никакой репликации нам не нужно, т.к. на серверах нет никаких данных и реплицировать в принципе-то нечего.

Третье – это сервера с Apache. Тут вообще все просто. Главное поставить mod_proxy_ajp и сказать, чтобы он балансировал нагрузку между двумя Tomcat‘ами. Предполагаем, что для наших масштабов нам хватит вполне и одного сервера. Второй ставим для обеспечения высокой доступности, а чтобы не мучаться с покупкой отдельного балансировщика, мы просто на первом сервере поднимем некий «виртуальный» IP, который в случае проблем сможем переключить на второй сервер.

Итого, для Приложения 1 нам потребуются 6 серверов, каждый стоимостью ок. $1500-2000. Т.е. мы инвестируем в инфраструктуру $9000-12000.

Для Приложения 2 нам потребуется чуть больше железок. Точно также мы разворачиваем 6 серверов – для БД1, для J2EE и Apache. Для БД2 нам потребуется чуть больше дискового пространства – 2 ТБ. Для хранения данных нам понадобится 7 дисков 300 ГБ + 1 диск для Parity – и мы сделаем RAID5. В принципе, ничего необычного в сервере x86 c 8 дисками нет. Как будет работать MySQL с БД в 2ТБ оставим пока что за скобками. Наверно, для обслуживания такой БД потребуется и памяти чуть побольше, чем в случае с БД1. Пусть этот сервер нам обойдется в $5000. Плюс еще точно такой же для высокой надежности.

И еще нам нужен сервер под приложение, написанное на Си. Поскольку своих данных у него практически нет, то единственно критичным ресурсом для него будет процессор. А вопрос с процессором будет очень сильно зависить от того, как написано приложение – насколько хорошо оно паралеллится между несколькими процессорами и насколько важна ему мощность одного процессора или ядра? Если приложение не паралеллится, то можно забыть про новые многоядерные Xeon‘ы и главное, чтобы частота процессора была как можно выше. Если же оно все-таки паралеллится, то можно поставить 4-х-ядерный процессор и хотя бы частично решить проблему производительности. Частично, потому что важен ответ еще на второй вопрос – а какая мощность нужна приложению от одного ядра? Для обеспечения надежности, также как и в случае с Apache, поставим второй сервер и «виртуальный» IP, который будет прыгать с сервера на сервер.

Итого, для приложения 2 нам потребуются 10 серверов. Общая стоимость инвестиций – $22000-26000. Для двух приложений мы инвестируем от $31000 до $38000. Дешево и сердито.

Вариант 2 – AIX.

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

Приложение 1, СУБД – процессор практически не требуется, требуется память, но на такую систему 2 ГБ будет достаточно, и 100 ГБ на диске под данные. Под ОС отведем еще 10 ГБ.

Приложение 1, J2EE – процессор требуется, но не очень много. Обычно Java может выиграть от наличия двух процессоров, но занять их на все 100% - это маловероятно. Память – тех же 2 ГБ на наших объемах будет достаточно. Данных нет, а сам J2EE сервер, приложение и ОС все вместе хорошо уместятся в 10 ГБ.

Приложение 1, HTTP – а вообще ничего не требуется. Минимум процессор, минимум памяти, минимум диска.

Приложение 2, СУБД1 – 50 ГБ на диске для данных, память те же 2 ГБ, процессор может быть будет чуть больше использоваться, чем в случае с 1м приложением.

Приложение 2, СУБД2 – 2 ТБ на диске для данных, процессор и память тяжело оценить, но по идее 8 ГБ памяти для начала пойдет.

Приложение 2, J2EE – все, что сказано для Приложения 1, подойдет и здесь.

Приложение 2, Apache – все по минимуму.

Приложение 2, Сишная часть – диск по минимуму, память 2 ГБ, процессор выделим 1 ядро. Поскольку у процессоров Power высокие частоты, то программа вне зависимости от того, как она написана, должна неплохо работать с 1м ядром. В случае необходимости (большого выигрыша от паралеллизации задач) можно увеличить количество виртуальных процессоров.

Итого, нам требуется процессор – 0.1+0.2+0.1+0.5+1+0.2+0.1+1=3.2 CPU Power 4.7 ГГц. Память – 2+2+0.5+2+8+2+0.5+2=19 ГБ. Диск – 110+10+10+60+10+10+10+10=230 ГБ + 2 ТБ. 2ТБ считаю отдельно, потому в серверах Power стандартно лишь по 6 дисков в узле, на которых 2 ТБ не разместишь. Учитывая совокупные требования по памяти и процессорам мы вполне умещаемся в один сервер IBM Power520. Стоимость сервера с 4мя процессорами, 8 ГБ памяти и 2мя дисками 146 ГБ, если верить сайту IBM - $20102. Добиваем туда еще 12 ГБ памяти ($3113) и 2 дика по 300ГБ ($2100). Итого цена одного сервера - $25315. А к нему еще нужно прибавить стоимость FC-адаптера ($1510) и стоимость полки с дисками (DS3200 с 8 дисками по 300 ГБ - $10 087, и я не знаю, нужно ли к ней покупать лицензию для AIX). Таким образом цена всей этой конфигурации на 2 сервера и 1 СХД составит $63 737 даже по ценам сайта IBM, которые далеки от реальности.

Итого, по цене железа конфигурация с AIX будет стоить на 68% больше. А если сюда еще прибавить стоимость труда администраторов. Администратор Linux обойдется в 1500-2000 долларов (как еще один сервер с Linux), а вот администратор AIX выйдет дешевле сервера с AIX’ом, но дороже администратора Linux – ок $3000 придется выложить за грамотного специалиста. А в нашей конфигурации количество администраторов AIX и Linux будет одинаковым.

Что же может заставить выбрать в такой ситуации сервер IBM Power? Начнем с простого и самого актуального для больших датацентров – 10 серверов x86 будут кушать у Вас 3-5 кВт, а два сервера Power520 – 1 кВт. Экономия в год – от 3 до 5 раз. Это не очень большие деньги и они не окупят разницу в цене, но когда Вам не хватает электроэнергии в ЦОДе и Вы готовы покупать ее уже за любые деньги, но Вам не готовы ее продавать, это существенная экономия.

Также за разницу в цене Вы получаете надежность – всевозможные фенечки серверов IBM типа памяти Chipkill, динамической реаллокации процессоров и т.п., которые действительно облегчают жизнь администратора. Если у Вас сломался процессор на x86, то Вы можете смело идти покупать новый процессор на ближайший базар. То время, что Вы покупаете процессор, сервер будет лежать. Если у Вас сломался процессор Power, то сервер в большинстве случаев продолжит свою работу без каких-либо неприятных спецэфектов для администратора, но с выключенным одним процессором, а как следствие – с пониженной производительностью. То же самое относится и к памяти.

Ну и самое мое любимое – это виртуализация от IBM. Я, честно говоря, не видел более логичного и органичного решения виртуализации. Главное его отличие от всех остальных с моей точки зрения, что оно не мешает, а помогает администратору. Если в виртуализации для x86 Вам надо сначала поставить VMware, а затем виртуальные машины, производительность которых оставляет желать лучшего, то в виртуализации IBM у Вас есть выбор от полной виртуализации (SPLPAR и VIOS) до ее практически полного отсутствия (Dedicated LPAR с такими же Dedicated устройствами). При этом ничего дополнительного ставить не обязательно – Вам может лишь потребоваться VIOS, если Вы будете виртуализировать устройства ввода-вывода. Не будете – не нужен VIOS. При этом VIOS можно задублировать. Точно так же можно задублировать FSP, на котором и работает гипервизор.
Это все действительно похоже на рекламу, но там есть чего рекламировать, особенно по сравнению с x86. Если, например, брать виртуализацию, то она может позволить организовать на втором запасном сервере тестовую среду, практически не закупая дополнительное оборудование. А в случае с решением на х86 Вам пришлось бы закупить еще 5 серверов. Или предположим, Вам надо обновить прошивку на сервере. На x86, чтобы обновить BIOS, Вам придется перегрузить сервер, а для этого Вам придется договариваться с пользователями, другими администраторами, оформлять запросы на изменения и т.д. В случае с Power оформить запрос на изменение, конечно, тоже желательно, но во-первых, тут придется иметь дело только с 2мя серверами, а не с 10, а во-вторых, большинство апгрейдов Firmware на серверах Power non-disruptive – т.е. могут производиться без остановки сервера. Если после неудачного обновления BIOS‘а на x86 Вам придется заново обновлять BIOS, откатываясь на старую версию, то в случае с серверами Power у Вас в сервере может быть две Firmware и Вы сами можете выбрать, какую из них использовать.

В общем, если Вы не знаете, что использовать – Linux или AIX – используйте то, что Вам больше нравится и помните:

No one have ever got fired for buying IBM ;)

PS: Спасибо Andrewk за этот пост!!! Браво!