История удаленного управления серверами — это история борьбы с расстоянием. С момента появления первых дорогостоящих мей��фреймов, работавших, дай бог, на перфокартах, инженеров стал волновать вопрос — как контролировать критически важное оборудование, не находясь рядом с ним 24/7? Ответом стала череда технологических решений: от примитивных терминалов на выделенных линиях до сложных сетевых архитектур и, наконец, интеллектуальных встроенных контроллеров. В этой статье рассмотрим ключевые этапы этого пути — от проприетарных систем 1970-х (IBM SNA) через трансформацию 1990-х к рождению универсального стандарта IPMI. Мы постараемся как можно интереснее рассказать об ИТ-ландшафте, заложившем основу для современных инструментов управления серверами. Где-то пройдемся по верхам, где-то остановимся чуть подробнее.
1970-е: первые серверы и ранние средства удаленного контроля
Прежде чем говорить об эволюции средств управления, нелишним будет разобраться с самим «пациентом» — в какой момент человечество в принципе задумалось о компьютере, задачей которого является постоянное обслуживание запросов от других устройств.
В 1969 году в документе RFC 5, описывающем ARPANET, слово server впервые упоминается в качестве антонима к термину user. А в Jargon File, сборнике профессионализмов и жаргонизмов, принадлежащих технологической сфере, дается следующее определение от 1981 года:
SERVER n. A kind of DAEMON which performs a service for the requester, which often runs on a computer other than the one on which the server runs.
Иными словами, под сервером тогда понималась не столько сама машина, сколько как процесс или стек ПО, которое на ней запущено. Существуют и более ранние упоминания слова «сервер», но в большинстве своем они относятся к вещам, далеким от современных компьютеров.
Мы специально делаем эту оговорку: первые серверы, речь о которых пойдет ниже – не совсем отвечают современной терминологии. Это были, скорее, не особые «обслуживающие» компьютеры, а фактически машины «все в одном», выполняющие специфические научные или рабочие задачи.
Итак, отправной точкой статьи станут 1970-е. Тогда все еще процветали мейнфреймы – гиганты наподобие IBM System/370 и более ранних CDC 6000 и UNIVAC 1108. Они буквально занимали целые залы и потребляли энергии, как небольшой завод. Стоили они тоже немало. Эти машины были сердцем корпоративных и государственных информационных систем: с их помощью вели учет банковских транзакций, обрабатывали переписи населения и управляли космическими миссиями.
Уже тогда инженерам, занятым обслуживанием мейнфреймов, хотелось упростить себе работу и выполнять хотя бы базовые задачи удаленно. Тогда еще не было ни SSH, ни веб-интерфейсов – для удаленного взаимодействия с машинами использовались терминалы — обыкновенные телетайпы или дисплейные станции наподобие IBM 2260. Они подключались к основной системе через коаксиальные кабели или модемные линии.
В экосистеме IBM существовала концепция системного оператора, который через специальный терминал с привилегированным доступом мог отправлять команды, наблюдать за системными сообщениями, управлять периферийными устройствами, инициировать дампы памяти или перезагрузку.
Консоли управления часто подключались локально, но крупные учреждения (банки или центры обработки данных NASA) начали использовать многоточечные консольные системы — Multiple Console Support (MCS) в среде MVS. MCS позволяла распределить функции оператора между несколькими терминалами, в том числе находящимися в разных помещениях или даже на разных площадках, при условии, что они были подключены к общей системе через выделенные линии связи — например, при помощи IBM 3705 Communications Controller, который обеспечивал сетевое взаимодействие по протоколам типа SNA (Systems Network Architecture, проприетарная архитектура IBM, предложенная в 1974 году).
В середине 1970-х IBM рассматривала себя в качестве поставщика оборудования для вычислительных систем, поэтому все ее инновации были направлены на увеличение продаж. Цель SNA заключалась в снижении затрат на эксплуатацию большого числа терминалов и стимулировании клиентов к разработке или расширению интерактивных терминальных систем. Это позволяло значительно увеличить отдачу от продажи терминалов и, что важнее, мейнфрейм-компьютеров и периферийных устройств. Но существовали и другие, на сей раз технические предпосылки, обеспечившие появление SNA.
IBM стремилась снизить основные некомпьютерные затраты и разрешить трудности, связанные с эксплуатацией крупных сетей, работавших на более ранних протоколах связи.
Например, линии нельзя было разделить между терминалами разных типов, так как они использовали разные «диалекты» существующих протоколов. В начале 1970-х и сами компьютеры, и периферические устройства были настолько дорогими, громоздкими и разнокалиберными, что включить универсальные коммуникационные интерфейсные карты в терминалы было попросту невозможно. К тому же сами линии связи очень сильно недотягивали по качеству до желаемых показателей. Фактически невозможно было построить линию dial-up со скоростью более 19 200 бит в секунду из-за зашкаливающего количества ошибок. В начале 1970-х лишь немногие линии могли похвастаться скоростью более 2400 бит в секунду.
С финансовой точки зрения SNA способствовал увеличению расходов клиентов на терминальные системы и вместе с тем делал продукты IBM основной статьей этих расходов. Помимо этого, SNA позволял преодолеть ограничения архитектуры, которые мейнфреймы IBM System/370 унаследовали от System/360. Каждый процессор мог подключаться не более чем к 16 каналам ввода-вывода, а каждый канал мог обслуживать до 256 периферийных устройств — то есть максимум 4096 периферийных устройств на процессор. На момент проектирования SNA каждая линия связи считалась периферийным устройством. Таким образом, количество терминалов, с которыми мощные мейнфреймы могли бы общаться, было ограничено.
SNA еще долгое время широко использовался в сетях банков, различных финансовых организаций и госучреждений. В 1999 году насчитывалось примерно 3 500 компаний с 11 000 SNA мейнфреймов.
В сентябре 2002 года IBM объявила, что больше не будет производить новые 3745 и сообщила даты окончания поддержки в Японии, Европе и на Ближнем Востоке. Примечательно, что Америка и некоторые страны Азии на тот момент в «расстрельный» список не попали.
Аналогичные решения были и у других производителей (Honeywell Bull, DCA, DECnet и др.), но мы не будем на них останавливаться, а вместо этого переместимся на 10-15 лет вперед.
1980-е: эволюция систем управления мэйнфреймами
В 1980-х годах подход к управлению мэйнфреймами эволюционировал, отчасти из-за того, что стало появляться все больше комплексных ИТ-инфраструктур, отчасти из-за бума микрокомпьютеров.
Так, к 1984 году оценочные продажи настольных компьютеров ($11,6 млрд) впервые превысили рынок мейнфреймов ($11,4 млрд) — это при том, что IBM получала основной доход именно от своих «больших» систем. Объясняется этот факт просто: во многих компаниях микрокомпьютеры стали понемногу вытеснять мейнфреймы младших моделей.
Начавшийся еще в середине 1970-х передел зон влияния на компьютерном рынке к концу нового десятилетия окончательно сосредоточился вокруг нескольких гигантов. Среди них – все та же IBM, Unisys и Digital Equipment Corporation. На детище последних – мейнфрейме VAX остановимся поподробнее.
В 1986 году DEC в попытках угнаться за IBM, начала разработку мейнфрейма VAX 9000. Он должен был прийти на смену прошлой премиальной модели 8800 и задумывался как полноценный «убийца» IBM. Так, предлагалось внедрить высокопроизводительную систему водяного охлаждения Aquarius, но в ходе исследований получилось настолько улучшить воздушную систему Aridus, что «водянка» даже не понадобилась. Успех PDP-11 по-прежнему кружил корпоративным боссам головы, и они решились на серьезную авантюру, обернувшуюся не менее мощным провалом.
DEC позиционировала систему 9000 как мейнфрейм с рекордной производительностью и ценой гораздо ниже аналогов от IBM. Компания вложила около миллиарда долларов в попытку вернуться на рынок мейнфреймов, который она покинула в 1983 году, уступив нижний сегмент IBM-совместимым ПК и Unix-станциям. Однако задержки в производстве (компьютер вышел на рынок только в 1990 году) и стремительный рост производительности RISC-процессоров, включая собственный NVAX от DEC, сделали 9000 устаревшим еще до выхода: аналогичную производительность стало возможно получить за гораздо меньшие деньги. Всего было поставлено около 40 систем — и проект, стоимость которого в итоге перевалила за $3 млрд, стал одним из крупнейших фиаско на рынке.
Закончим эту историю одним курьезным прецедентом. Компании DEC было хорошо известно, что многие ее компьютеры «оседают» в советских НИИ и подвергаются реверс-инжинирингу. В качестве насмешки на одном из чипов DEC была помещена гравировка, сделанная на ломаном русском языке: «CBAKС… Когда вы заbатите довольно воровать настоящий лучший», что в вольном переводе означает «CVAX — когда ты хочешь воровать только самое лучшее».
Как вы видите, ландшафт 1980-х был весьма непрост. Компании взлетали и исчезали, рынок сотрясали микрокомпьютеры и все более мощные мейнфреймы. Часть управленческих задач, ранее выполнявшаяся исключительно на терминалах, к середине-концу десятилетия перешла под управление на��тольными ПК. Параллельно на нем развивалась и сетевая инфраструктура. Протокол SNA (Systems Network Architecture) от IBM стал стандартом де-факто в корпоративных средах, а с появлением TN3270 стало возможно подключаться к мейнфрейму через TCP/IP-совместимые сети через шлюзы между SNA и IP. Системные администраторы теперь могли управлять мэйнфреймами откуда угодно, хоть из другого города — достаточно было соединения по выделенной линии или даже через коммутируемую сеть.
IBM одной из первых осознала необходимость комплексного подхода к управлению сетями и в 1986 году представила фреймворк Open Network Management (ONA), описывающий обобщенную архитектуру сетевого управления. Его ключевым компонентом которого фактически стал NetView, первый инструмент управления сетями на вычислительных машинах IBM. NetView обеспечивал централизованное управление сетями SNA — мониторинг, контроль и изменение конфигураций. С тех пор IBM значительно расширила и усложнила свою сетевую управляющую платформу, превратив ее в масштабную и многофункциональную систему.
Роль оператора с течением времени также трансформировалась: рутинные задачи все чаще передавались автоматизированным системам, а человек стал заниматься скорее координацией, анализом и стратегическим управлением. Так, к концу 1980-х удаленное управление мейнфреймом уже не выглядело как нечто фантастическое. И хотя «удаленка» тех лет была медленной, закрытой и требовала специального оборудования, именно тогда были заложены основы того, что позже превратится в современные системы out-of-band управления, IPMI и облачные консоли.
1990-е: переосмысление мейнфреймов и начало новой эры
В 1990-х годах мейнфреймы, вопреки многочисленным прогнозам об их скором исчезновении, не только выжили, но и прошли значительную трансформацию, адаптировавшись к новым технологическим и рыночным реалиям.
На рубеже 1980–1990-х мейнфреймы переживали серьезный кризис: рынок завоевывали дешевые Unix-станции и PC-серверы. IBM, по-прежнему доминировавшая в этом сегменте, столкнулась с резким падением продаж и рядом внутренних проблем. Однако вместо отказа от платформы компания приняла стратегическое решение — модернизировать, а не ликвидировать мейнфреймы как класс.
Ключевым шагом стал выпуск в 1990 году системы IBM ES/9000 и революционной линейки IBM System/390 (S/390). S/390 не только сохранила совместимость с предыдущими поколениями (вплоть до System/360 образца 1960-х!), но и получила в 1994 поддержку CMOS-процессоров, что резко снизило стоимость, энергопотребление и габариты. Если раньше мейнфрейм занимал целую комнату, то теперь его можно было разместить в стандартной серверной стойке.
Особое внимание уделялось открытости системы к коммуникациям с «внешним миром»: в S/390 была внедрена поддержка TCP/IP, что позволило мейнфреймам напрямую взаимодействовать с ресурсами в глобальной сети.
Не менее важно и то, что мейнфреймы стали дешевле в обслуживании: благодаря встроенным средствам диагностики, удаленного управления (в том числе через новые сетевые протоколы) и отказоустойчивой архитектуре, стоимость владения мейнфреймом для критически важных нагрузок оказалась ниже, чем у ферм Unix-серверов.
1990-е стали для мейнфреймов эпохой переосмысления и возрождения популярности в корпоративном сегменте. Но, тем не менее, рынок все равно менялся – и мейнфреймы на ландшафте середины-конца 1990-х начали выглядеть своеобразными «белыми воронами».
Драйвером перемен стал взрывной рост локальных сетей и интернета. Компании начали массово внедрять файловые, почтовые, а затем и веб-серверы. То, что ранее считалось привилегией крупного бизнеса, стало входить в рутину малых и средних компаний. На этом фоне резко возрастает спрос на дешевые, масштабируемые и простые в управлении решения. Именно тогда начинает доминировать архитектура на базе x86-процессоров. Серверы от Dell, Compaq, HP и других производителей начинают походить на ПК гораздо сильнее, чем их предки.
Операционные системы тоже меняются: на сцену врываются Windows NT Server и (несколькими годами позже) Linux. Классическим Unix-системам приходится посторониться и занять высоконагруженный корпоративный сегмент.
Что касается систем управления – вплоть до начала 2000-х системы управления серверами развивались в русле повышения отказоустойчивости и упрощения удаленного администрирования. Компании внедряли как готовые отраслевые, так и собственные решения, позволявшие подключаться к серверу через основной или служебный канал — в том числе по телефонной линии или последовательному соединению. Эффективное управление предполагало мониторинг состояния оборудования, оповещение об ошибках, ведение журналов, дистанционную настройку и возможность вмешательства в работу сервера даже при неработающей ОС.
Особое внимание уделялось встраиваемым аппаратным средствам. Уже в середине 1990-х на серверных платах Intel появились специализированные контроллеры, измерявшие напряжения, температуру и контролировавшие вентиляторы через шину I²C. В 1997 году в платформе Buckeye впервые применили подход, заложивший основу современного BMC (Baseboard Management Controller): это был отдельный микрокомпьютер на базе Philips 87C552 с собственной ОС, постоянно отслеживающий состояние системы — от нажатия кнопок до температуры компонентов.
Контроллер управления на платформе Nightshade стал еще более автономным: он объединил функции нескольких ранее раздельных компонентов и получил порт аварийного управления (EMP), позволявший через модем или нуль-модемное соединение включать/выключать сервер, просматривать журнал событий (SEL), данные с датчиков (SDR) и перехватывать текстовую консоль.
Параллельно Intel совместно с HP, NEC и Dell разрабатывала IPMB и ICMB — интеллектуальные шины управления платформой и шасси. Благодаря появлению в серверных решениях новых микросхем на базе StrongArm стало возможным интегрировать в BMC полный набор функций, включая мост IPMB-ICMB. Контроллеры стали поддерживать новую версию отраслевого стандарта — IPMI 1.5. Ключевым усовершенствованием стало появление поддержки локальной сети Ethernet для внешней связи, в то время как предыдущая версия (IPMI 1.0) полагалась преимущественно на шину ICMB или последовательный порт (Serial EMP). Это нововведение обеспечило по-настоящему независимый мониторинг и управление аппаратной частью сервера — независимо от состояния его основной операционной системы или даже самого сервера.
Со своей стороны, HP с начала 1990-х активно развивала технологии удаленного администрирования. К концу десятилетия компания выпустила решения семейства Remote Insight Lights-Out, включавшие аппаратные платы с возможностью полного контроля сервера через сеть — независимо от состояния ОС. Эти системы обеспечивали графический доступ через веб-браузер, виртуальные носители и управление питанием, заложив основу для будущих встроенных решений ��роде iLO. Подробнее об этой части истории удаленного управления можно прочитать в замечательной статье Byte от 2008 года.
Так или иначе, ключевые принципы, заложенные в 1990-х, остались неизменны: независимость от состояния ОС, средства аппаратного мониторинга, виртуальные носители и веб-интерфейсы. Сегодня эти идеи продолжают развиваться в форматах Redfish, облачных консолях и zero-touch-развертывании, но суть остается — обеспечить полный контроль над «железом» на расстоянии, без физического присутствия. Именно благодаря решениям, рожденным еще полвека назад, современные дата-центры масштабируются, управляются и восстанавливаются почти без участия человека.