Курсовая работа: Серверные платформы RISC/UNIX
Курсовая работа: Серверные платформы RISC/UNIX
История проекта Alpha
Говоря о RISC/UNIX-платформах, нельзя не вспомнить проект Alpha. В 1989 году компания Digital Equipment Corporation. (DEC), подталкиваемая моральным старением собственной VAX-архитектуры и стремительным натиском перспективных RISC-платформ, принялась за создание инновационной 64-разрядной RISC-архитектуры, ориентированной на максимально возможную совместимость с системами VAX, чтобы облегчить перенос операционной системы VAX/VMS и всего наработанного за предыдущие годы сопутствующего ПО на новую, более производительную и гибкую аппаратную среду.
Первые более или менее подробные сведения об архитектуре Alpha относятся к 1992 г. Тогда же было оговорено, что термин Alpha — это кодовое наименование, и к моменту выпуска первых процессоров оно будет заменено официальным. Согласно анонсам, новая платформа имела 64-разрядную RISC-архитектуру с инструкциями фиксированной (32 бита) длины. Подробнее о процессорах Alpha можно прочитать в разделе «Процессоры».
Вскоре проект вступил в производственную стадию, все силы, связанные с ним, были реорганизованы в одно из ведущих подразделений корпорации DEC. Новая архитектура получила официальное название АХР или Alpha АХР, планировалось, что время ее активной жизни составит как минимум 25 лет.
Первый процессор из семейства Alpha имел индексное обозначение 21064, где часть 21 указывала на то, что Alpha — архитектура XXI века, 0 означал порядковый номер процессорного поколения, а 64 — разрядность архитектуры в битах. Кроме того, ему присвоили кодовое наименование EV4, которое по одной из не подтвержденных официально версий является аббревиатурой «Extended VAX». Цифра 4 на конце означает поколение технологического процесса, в данном случае это CMOS4. Интересно, что в дальнейшем кодовое название стало даже более распространенным, чем официальные индексы, и поколения процессоров семейства Alpha определяются и отсчитываются именно по нему.
Первые наборы системных микросхем для поколения EV4 были рассчитаны на использование периферийных шин TURBOchannel, FutureBus+ и XMI; однако, несмотря на техническое совершенство, они не получили широкого распространения из-за небольшого количества совместимого оборудования. В начале 1994 г. был представлен набор системных микросхем DEC Apecs в вариантах с 64- и 128-разрядной шиной данных, ориентированный на стандартные шинные архитектуры PCI и ISA/EISA, при этом работа с шинами ISA и EISA была реализована посредством внешних стандартных мостов.
Разработка реальных продуктов на базе архитектуры Alpha нисколько не отставала от процесса совершенствования ее самой — уже в ноябре 1992 г. на базе процессора EV4 с тактовой частотой 150 МГц и соответствующего системного окружения была построена первая рабочая станция архитектуры Alpha — DEC 3000 Model 500 АХР (кодовое наименование Flamingo).
Для поколения EV5 был разработан НМС DEC А1соr со следующими параметрами: частота системной шины 33 МГц, использование до 64 Мбайт внешней кэш-памяти и до 8 Гбайт оперативной памяти FPM ЕСС (при разрядности шины памяти 256 бит), совместимость с 64-разрядной 33-МГц шиной PCI. Работа с шинами ISA/EISA, как и прежде, была реализована посредством внешнего контроллера. Дисковый контроллер стандарта IDE отсутствовал, однако была предусмотрена возможность интеграции отдельной микросхемы независимых изготовителей. Одновременно с запуском в производство EV56 была выпущена модификация Alcor, поддерживающая BWX, — Alcor 2. В дальнейшем появился НМС Pyxis, обеспечивший работу с системной шиной на частоте 66 МГц и использование 66-МГц оперативной памяти SDRAM ЕСС (при разрядности шины памяти в 128 бит).
Для процессоров серии 21264 (EV6) было спроектировано два набора системных микросхем — DEC Tsunami (известных также как Typhoon) и AMD Irongate или AMD-751. Решение корпорации DEC было направлено на повышение масштабируемости платформы Alpha: на основе Tsunami проектировали однопроцессорные, двухпроцессорные и четырехпроцессорные системы с разрядностью шины памяти от 128 до 512 бит. В качестве ОЗУ использовались модули регистровой памяти SDRAM с ЕСС-коррекцией, работающие на частоте 83 МГц. НМС DEC Tsunami обеспечивал работу сразу нескольких 64-разрядных 33-МГц шин PCI. Гибкость построения конечных систем достигалась благодаря разделению НМС на множество обособленных компонентов. В распоряжении разработчиков находились контроллеры системной шины — C-chips (по одному на каждый процессор), контроллеры шины памяти — D-chips (по одному на каждые 64 разряда шины) и контроллеры шины PCI — P-chips (по одному на каждую требуемую шину). Впрочем, подобный подход имел и некоторые недостатки — в некоторых системах, например AlphaPC 264DP, совокупное число используемых микросхем доходило до 12, что отрицательно сказывалось на их конечной стоимости. НМС AMD Irongate разрабатывался изначально как «северный мост» для системных плат под процессоры Athlon, однако его также использовали в некоторых решениях для семейства Alpha — например UP1000 и UP 1100. Irongate представлял собой одну-единственную микросхему, а потому стоил намного дешевле DEC Tsunami, а, кроме того, обладал более низким энергопотреблением. Однако из-за отсутствия многопроцессорности и узкой шины памяти он не позволял серьезно раскрыться потенциалу процессоров семейства 21264.
1998 г. ознаменовался для платформы Alpha серьезными событиями, сулившими неплохое будущее — в феврале 1998 г. между DEC и Samsung было заключено соглашение, которое предоставляло последней доступ ко всем патентам по архитектуре Alpha, а также позволяло выпускать уже разработанные DEC модели и даже создавать собственные, а в июне 1998 г. уже Compaq, поглотившая к тому времени DEC, совместно с Samsung организовали альянс по развитию архитектуры Alpha. Среди прочих мер была учреждена дочерняя компания Alpha Processor Inc. (API), занявшаяся маркетинговыми вопросами и продвижением архитектуры. Летом 1998 г. началось массовое производство систем на базе EV6. Помимо Samsung, по условиям договора с DEC, процессоры EV6 производились и на мощностях корпорации Intel.
Однако процесс интеграции подразделений DEC в структуры Compaq привел к тому, что уже через полгода DEC окончательно прекратила свое существование. С этого момента фактически и начинается закат платформы Alpha.
Со времен независимости DEC платформа Alpha как открытая архитектура была ориентирована на использование целого ряда операционных систем. Речь прежде всего идет о Microsoft Windows NT, Digital UNIX (также известной как DEC OSF/l, и позднее, как Compaq Tru64 UNIX) и OpenVMS, причем приоритеты были расставлены именно в таком порядке. Кроме этих систем, на Alpha были портированы ОС независимых поставщиков и некоммерческие ОС, такие, как Linux и BSD всех разновидностей, однако никакой поддержки с официальной стороны они не получили и использовались крайне незначительно.
Среди всех известных RISC-платформ Alpha, пожалуй, единственная, которая была способна реально работать с Windows NT, ибо еще в 1997 г. корпорация Microsoft свернула поддержку архитектур PowerPC и MIPS. Однако количество приложений для Alpha было во много раз меньше, чем для х86. Частично ситуацию помогал исправить эмулятор и транслятор кода х86 в код Alpha, именуемый FX132 и выпущенный в 1996 г. Однако его использование снижало производительность систем на 40% и больше по сравнению с изначально откомпилированными под Alpha приложениями. Нерешенной ос тавалась и проблема драйверов для периферийных устройств: транслятор FXI32, естественно, оказался неприменим, а очень многие производители сочли разработку драйверов для Alpha нецелесообразной, так что заказчикам приходилось рассчитывать в основном на Microsoft и DEC. И, наконец, самый важный момент, характеризующий ошибочность выбранной DEC системы приоритетов: даже работая на 64-разрядной архитектуре Alpha, Windows NT оставалась 32-разрядной и не могла полностью раскрыть заложенный в аппаратуру потенциал.
Согласно статистике Compaq, среди всех предустановленных на Alpha-системах ОС 60% принадлежало Tru64 UNIX, 35% — OpenVMS, а на долю Windows NT приходилось около 5%. Очевидно, что дальнейшие работы над этой ОС были бессмысленны. Учитывая сложившуюся ситуацию, 23 августа 1999 г. Compaq отказалась от участия в развитии Windows NT и прекратила поставлять ее со своими Alpha-системами. Неделю спустя Microsoft объявила, что прекращает работу над портированием Windows 2000 на платформу Alpha.
В декабре 1999 г. компании Compaq и Samsung подписали меморандум о намерении инвестировать 500 млн. долл. США в развитие архитектуры Alpha: Samsung — 200 млн. на отладку новых технологических процессов, a Compaq — 300 млн. на проектирование новых серверных решений и на дальнейшее развитие Тru64 UNIX. В том же месяце Compaq и IBM оформили соглашение, по которому последняя будет изготавливать процессоры Alpha по своей технологии на медных проводниках, но Samsung останется основным поставщиком процессоров Alpha. Однако в 2000 г. Samsung не успела наладить 180-нм процесс, и рынок был вынужден довольствоваться процессорами EV67 и небольшими вкраплениями EV68C. В начале 2001 г. она все же организовала массовый выпуск процессоров EV68A, однако момент был упущен — Compaq уже планировала переориентировать производство систем AlphaServer GS-класса, а также развернуть модернизацию используемых систем с применением процессора EV68C, поставляемого IBM.
25 июня 2001 г. произошло историческое событие, поставившее окончательную точку на будущем платформы Alpha: корпорация Compaq объявила о планах поэтапного перевода к началу 2004 г. всех своих серверных решений на архитектуру IA-64. Результатом этого объявления стало немедленное прекращение работ над поколением EV8. EV7 стало финалом многолетней деятельности подразделения Alpha Microprocessor Division — после официального объявления о начале производства процессоров, намеченного на начало 2002 г., оно подлежало расформированию, а костяк инженеров планировалось перевести на работу в компанию Intel. Выдержав непродолжительную паузу, Samsung и IBM прекратили производство процессоров Alpha на своих мощностях. 21 октября 2001 г. компания API, переименованная на тот момент в API Networks, передала все полномочия по поддержке Alpha-систем компании Microway — крупнейшему после Compaq сборщику рабочих станций и серверов на архитектуре Alpha и старому партнеру DEC.
На этом по логике вещей история должна была бы закончиться, однако 3 сентября 2001 г. компания HP объявила о планах по слиянию с Compaq, которые в итоге отсрочили закат платформы Alpha на десятилетие. Вопреки ожиданиям, Hewlett-Packard не только не свернула поддержку Alpha-систем, но и взяла на себя труд по выпуску процессоров и дальнейшему развитию поколения EV7, хотя и в ограниченном объеме.
В августе 2004 г. в производство была запущена последняя модификация архитектуры Alpha — процессор с кодовым именем EV7z, работающий на частоте 1,3 ГГц и изготавливаемый с применением 180-нм проектных норм. По архитектуре он не отличался от прародителя EV7.
В специальном меморандуме, вышедшем в момент объявления EV7z, было заявлено, что никаких иных воплощений архитектуры Alpha больше не будет, однако серверы и рабочие станции, созданные на ее базе, останутся доступными под маркой HP до 2006 г., а их техническое обслуживание продлится до 2011 г.
Несостоявшееся поколение EV8 (процессоры с индексом 21464) должно было стать дальнейшим развитием идей, заложенных в EV7- Предполагалось вдвое увеличить количество основных функциональных устройств, доведя число целочисленных конвейеров до восьми, а вещественных — до четырех, расширить объем кэш-памяти до 3 Мбайт, реализовать многопоточную обработку данных с использованием технологии SMT (Simultaneous Multi-Threading), которая должна была позволить одновременное выполнение до четырех программных потоков внутри одного ядра. Однако этим планам не суждено было реализоваться — EV8 никогда не увидит свет. Впрочем, история платформы Alpha на этом не обрывается — значительное количество технических специалистов перекочевало из подразделения Alpha Microprocessor Division в компанию AMD, хорошо известную на рынке систем с архитектурой х86. Там, используя свой опыт, знания и наработки, они занимались проектированием успешной платформы AMD64, во многом наследующей идеи проекта Alpha.
Серверы HP
Компания Hewlett-Packard вступила в завершающую стадию перевода своих «тяжелых» серверов с архитектуры РА-RISC (ЦП 8x00) на архитектуру IA64 (ЦП Itanium 2). Серверы AlphaServer на процессорах Alpha пока еще продаются, но их дни сочтены. Более подробно об этих архитектурах рассказано в разделе «Процессоры». Особенность переходного этапа заключается в том, что компания одновременно с новыми Itanium-серверами Integrity продолжает выпускать модели серии HP 9000. Последнее поколение этой серии строится на процессорах 8900 с тактовыми частотами 800 или 1000 МГц и наборах микросхем zxl (в младших моделях) и sx1000 (в средних и старших), таких же, как в серии Integrity.
Унификация конструктивного исполнения обеих серий максимально упрощает модернизацию серверов 9000 до соответствующих моделей Integrity — в большинстве случаев для этого достаточно извлечь старую процессорную ячейку (терминологии HP), перенести из нее модули памяти в новую и вставить новую ячейку на место старой. При работе под управлением ОС HP-UX 11i v2 для ряда моделей серверов такая замена может производиться без остановки и перезагрузки машины.
Для построения гибких масштабируемых систем масштаба предприятия серверы серий 9000 и Integrity могут объединяться в кластеры. Узлы кластера, каждый из которых представляет собой самостоятельный сервер со своими процессорами и оперативной памятью, работающий под управлением своей ОС, соединяются при помощи стандартных сетевых интерфейсов. Для связи между узлами используются специальные протоколы связи и системные процессы. В состав кластера, помимо серверов, входят также дисковые системы, устройства резервного копирования, специализированное программное обеспечение кластерных конфигураций, программное обеспечение управления информационными технологиями HP OpenView, техническая поддержка, консультационные услуги и обучение.
В зависимости от требуемого уровня отказоустойчивости предлагаются несколько типов кластерных решений, в которых серверные узлы кластера могут быть размещены централизованно (локальный кластер), распределены по соседним зданиям (кампусный кластер), распределены по нескольким территориям в пределах одного города (метро-кластер) или представляют собой два связанных кластера, размещенных в различных городах, странах или континентах (континентальный кластер).
Архитектура HP HyperPlex применяется для задач, требующих интенсивного обмена информацией между серверами (узлами интегрированной системы), например, для консолидации информационных систем предприятия, ERP-приложений, организации распределенных вычислений, технического моделирования и компьютерной имитации. Основу HyperPlex составляет специальное оборудование HyperFabric2, обеспечивающее прямое либо коммутируемое высокоскоростное соединение между узлами на скорости до 4 Гбит/сек в полнодуплексном режиме на каждый порт. Архитектура поддерживает стандартные протоколы TCP/IP и НМР (Hyper Messaging Protocol), а также кластерные конфигурации с возможностью равномерного распределения трафика по всем имеющимся каналам (балансировка нагрузки).
Большинство серверов HP могут быть сконфигурированы как в виде единой мультипроцессорной системы, так и в виде нескольких аппаратно и/или программно независимых виртуальных разделов со своими ресурсами и операционной системой.
Серверы семейства HP оснащены рядом средств обеспечения высокой готовности: резервными вентиляторами и блоками питания с «горячей» заменой; дисками и контроллерами ввода-вывода «горячего» подключения; динамической очисткой и перераспределением страниц памяти; динамическим перераспределением процессоров; независимыми гнездами PCI; интегрированной службой оповещения о событиях Event Monitoring System (EMS), работающей в режиме реального времени; встроенной расширенной системой обнаружения неисправностей с выделенным сервисным процессором и шиной.
Прогнозирование и предотвращение возможных сбоев реализуются путем непрерывного контроля состояния всех компонентов сервера и анализа тенденций изменения контролируемых показателей. При обнаружении какой-либо потенциальной проблемы, например, возможного перегрева процессора, специальные функции динамического перераспределения ресурсов (в данном случае функция DPR — Dynamic Processor Resilience) обеспечат перенос процессов с потенциально сбойного компонента на исправный без прерывания выполнения приложений. При этом администратор системы и/или служба технической поддержки получат уведомление и подробный отчет о происшедшем событии.
