Годы под солнцем. 20 лет в Sun Microsystems и Кремниевой долине

К сожалению, ценой этой «простоты» является низкая загрузка пропускной способности шины. Пока владелец шины ожидает, пока память выполнит его запрос на чтение или запись, шина простаивает. Таким образом, драгоценная пропускная способность шины просто тратится впустую. Низкая пропускная способность шины означает, что она может поддерживать лишь небольшое количество процессоров. В технической терминологии это называется низкой «масштабируемостью» (scalability). В 90-е годы, поскольку скорость процессоров росла гораздо быстрее, чем скорость памяти, задержка доступа к памяти (memory latency) по сравнению со скоростью процессоров становилась всё больше. Ограничения по масштабируемости становились всё более серьёзными.

Dynabus от Xerox, однако, очень похож на современные сетевые технологии. Владелец шины, отправляя запрос на чтение или запись в память, передает не только адрес цели, но и свой собственный идентификатор. Затем он освобождает шину, давая возможность другим процессорам воспользоваться ею. Когда память готова вернуть запрошенные данные, управляющая логика памяти запрашивает право владения шиной и передает запрошенные данные, используя идентификатор первоначального запрашивающего устройства. Такая характеристика разделения циклов значительно увеличивает пропускную способность шины и позволяет ей поддерживать большее количество процессоров. Для шинного проектирования того времени это было поразительным прорывом в концептуальном плане.(Вспоминая об этом много лет спустя, я убеждён, что карьера Проди в сфере сетей началась не с момента основания им компании Juniper Networks в 1996 году. Сети уже существовали в его воображении за десять лет до этого.)

Конечно, с инженерно-технической точки зрения ничего не бывает бесплатно. Реализация протокола кохерентности кэша для нескольких процессоров на Dynabus гораздо сложнее. Поскольку я не имел достаточного представления о том, как работает Dynabus, я скептически относился к протоколу кохерентности кэша для этой системы. Проди с улыбкой сказал мне, что может формально доказать (formally proof) эффективность этого протокола. Раньше я лишь слышал о существовании такого теоретического метода формального доказательства. Но сам я не знал, как это сделать.

Это заставило меня сдаться. Я с уважением смотрел на этого исследователя из Xerox. Я верил, что он сможет.

Ранние решения по проекту Sun Dragon

Как и ожидалось, Стив поручил мне руководить разработкой аппаратного обеспечения для проекта Sun Dragon. Через шесть месяцев компания Sun объединила подразделения серверов и рабочих станций. Руководителем был назначен Хол Ли. Он предложил мне заменить Стива на посту руководителя проекта Sun Dragon, а сам стал моим непосредственным начальником.

Одномодульная системная плата

Одним из решений, которые пришлось принять на самом раннем этапе проекта, было определение позиционирования продукта. Технология «Xerox Dragon», над которой мои коллеги из Xerox работали с 1985 года, обладала богатыми возможностями и высокой масштабируемостью. Еще до моего прихода в проект эти эксперты из Xerox решили, что вся система будет построена по модульной архитектуре. В отличие от распространенного в то время в мире супермини-компьютеров подхода, включая DEC VAX-11, где использовались отдельные платы процессора, памяти и ввода-вывода, Sun Dragon имел только одну печатную плату. Два процессора, их вспомогательные кэш-памяти, часть оперативной памяти и логика ввода-вывода — всё это находилось на одной плате. Соединительная шина всей системы, Dynabus, не просто подключалась к краю платы, как в большинстве многопроцессорных систем. Эта шина проникала внутрь платы, благодаря чему вся оперативная память и устройства ввода-вывода на всех платах, независимо от того, на какой именно плате они находились, имели равный статус на шине.

Когда я присоединился к этому проекту, мне рассказали об этом решении. Я был очень рад, потому что, как, вся команда могла сосредоточиться только на одной печатной плате, за исключением задней панели корпуса. Это также упрощало масштабирование системы. Если заказчик хотел расширить систему для повышения производительности, ему достаточно было просто установить дополнительные платы SunDragon! Спустя более двадцати лет, глядя на блейд-серверы Cisco Systems «Unified Computing System» (UCS), я вдруг осознал, что система Sun Dragon фактически является прародителем современных блейд-серверов! Единственное отличие заключается в том, что системные платы Sun Dragon вставлялись в корпус вертикально, тогда как сегодня большинство плат блейд-серверов размещаются горизонтально.

Интересно, что у такой конструкции с одной системной платой есть дополнительное преимущество. В конце 80-х — начале 90-х годов Sun была лидером на рынке рабочих станций. Основатели компании явно поощряли культуру, направленную против чрезмерной сложности системного дизайна. Это отражалось в ряде неписаных правил, касающихся всех системных продуктов. Например, время загрузки компьютера не должно было превышать тридцати секунд, а в продукте могла быть только одна (материнская) плата. Чувствуете дух рабочих станций? Ни один пользователь рабочей станции не любит сидеть перед ней, долго ожидая запуска системы. Это правило кажется вполне разумным.

К сожалению, процедура запуска системы включала проверку файловой системы и тестирование оперативной памяти. Поэтому время, необходимое для запуска, было прямо пропорционально их размеру. Объем оперативной памяти и емкость устройств хранения на серверах значительно превышали аналогичные показатели рабочих станций. Тщательное самотестирование перед запуском пользовательских приложений — это именно то, что должен делать сервер. На это требуется больше времени. Мы вынуждены были нарушить это правило. К счастью, хотя пользователи рабочих станций обычно выключают их в конце рабочего дня, серверы, по крайней мере в США, обычно не выключают. (Мы, правда, слышали, что в некоторых других частях мира в то время это делали.) Нам несложно было оправдать длительность запуска Sun Dragon, составлявшую несколько минут, тем, что перезагрузка происходила нечасто.

Другое правило — «если у продукта только один тип платы, это не так легко объяснить» — объяснить гораздо сложнее. Как компания, у которой подавляющее большинство продуктов представляло собой рабочие станции в корпусе типа «коробка для пиццы» с установленным на ней монитором, Sun в принципе не любила производить супермини-компьютеры с многоплатными стоечными корпусами! Поверите или нет, но несмотря на то, что инженеры Xerox разработали эту лаконичную модульную конструкцию исключительно из-за возможностей Dynabus, совершенно не подозревая о существовании такого правила, мы на соответствующих совещаниях всё же настаивали на том, чтобы проект Sun Dragon состоял только из одной платы — « »!

Продукты Sun Dragon действительно могли работать в архитектуре, состоящей из одной единственной платы с двумя процессорами, некоторой объёмом памяти и полным набором входов-выходов. Если заказчикам требовалась более высокая вычислительная мощность или больший объём памяти, им достаточно было просто установить дополнительные (такие же) системные платы. Система ввода-вывода на системной плате представляла собой шину, называемую S-Bus, проходящую исключительно по плате. Она была изобретена одним из основателей Sun Microsystems и тогдашним вице-президентом по инженерным вопросам Энди Бекто-Сян и поддерживала четыре разъёма для модулей ввода-вывода. Заказчики могли выбрать и установить необходимые модули ввода-вывода.

Одна шина Dynabus

Dynabus фактически спроектирована таким образом, что до четырёх параллельных шин могут работать одновременно как одна шина. В связи с ограничениями, налагаемыми шириной стандартного 19-дюймового корпуса, каждая шина может поддерживать пять системных плат (всего десять процессоров). Учитывая, что в 1990 году все продукты Sun были однопроцессорными, а во всей компании — от инженерного отдела до отделов продаж, маркетинга, послепродажного обслуживания и производства — отсутствовал опыт работы с крупными системами, мы решили создать только самую минимальную архитектуру Dragon/Dynabus, то есть систему с одной шиной Dynabus.В результате, несмотря на то что архитектура Dragon/Dynabus, которой мы, партнеры Xerox, так гордились, могла поддерживать большее количество процессоров, продукты Sun Dragon будут иметь максимум десять процессоров.

Через шесть месяцев я однажды поговорил с Тоддом Линчем (Todd Lynch), моим коллегой по проекту Maxiray — рабочей станции на базе M-Bus с четырьмя процессорами, — который возглавлял отдел рабочих станций. Он упомянул, что полностью укомплектованную четырехпроцессорную систему Maxiray можно также использовать в качестве сервера. Во время разговора я не мог не почувствовать опасения по поводу пересечения продуктовых линеек (конкуренции), особенно учитывая, что мы оба использовали одни и те же процессорные модули, поставляемые отделом процессоров. Каждый год в конце весны в Sun начинается составление бюджета на новый финансовый год, начинающийся в июле. Как я уже упоминал, будучи молодой компанией с творческой культурой, Sun время от времени генерирует новые идеи и запускает новые проекты (не всегда официально одобренные). Процесс составления бюджета выявляет реальное положение дел, что зачастую приводит к отмене проектов и реорганизации подразделений. Некоторые проекты по своему характеру слишком схожи, особенно те, которые из-за небольшого объема производства рассматриваются компанией как второстепенные серверы, и эта опасность вызывает серьезные опасения.

Удвоение количества процессоров

Опираясь на свои знания об архитектуре Sun Dragon и модульном дизайне микросхем с матрицей логических элементов, используемом нашей командой, я принял одно из лучших решений в своей жизни: Sun Dragon удвоил количество поддерживаемых шин Dynabus, тем самым увеличив максимальное количество процессоров до двадцати! При этом нам удалось сохранить концепцию «одной платы». Благодаря модульной архитектуре Xerox модифицировать логику на системной плате оказалось на удивление просто. Системная архитектура с двумя шинами не только удвоила пропускную способность всей системы (и, следовательно, максимальное количество процессоров ), но и обеспечила избыточность (redundancy), которая крайне важна для серверов. Даже в случае выхода из строя одной из шин «Sun Dragon» он сможет продолжить работу. Эта модификация сделала «Sun Dragon» более устойчивым, а ещё большее отличие от «Maxiray» с четырьмя процессорами сделало оба проекта более «безопасными».

Этот «увеличенный» Sun Dragon действительно столкнулся с проблемами через два года из-за сложностей с послепродажным обслуживанием и производственными мощностями. Об этом я расскажу позже.

Модульная архитектура Sun Dragon имела ещё один интересный эффект, приведший к появлению производных продуктов. За девять месяцев до запланированной поставки Sun Dragon в мае 1993 года мы действительно создали уменьшенную версию Sun Dragon с одним-единственным Dynabus, используя те же самые чипы матрицы Sun Dragon. Мы назвали её «Скорпион» (Scorpion). Но это уже совсем другая история.

Транзисторная логика Ганнинга (GTL)

Среди множества инноваций «Sun Dragon» я должен упомянуть физическую технологию под названием GTL, изобретённую академиком Xerox Биллом Ганнингом (Bill Gunning). Работая в Xerox PARC, Билл первым создал сеть Ethernet со скоростью 3 мегабита в секунду. Когда он присоединился к команде Xerox, переехавшей в Sun, ему было уже 83 года. Но он по-прежнему выглядел полным энергии и сохранял ясный ум. В команде его глубоко уважали.

В 80-е и начале 90-х годов наиболее распространенной в отрасли цифровой логикой была изобретенная компанией «Texas Instruments» логика «транзистор-транзистор» (Transistor-to-Transistor Logic, или TTL).В схемах TTL напряжение +5 В соответствовало логическому «1», а 0 В — логическому «0». В конце 80-х годов постепенно стала внедряться более энергоэффективная комплементарная MOS-технология (CMOS). Однако в схемах CMOS по-прежнему использовались логические напряжения, характерные для TTL. Другая, более быстрая технология — эмиттерно-связанная логика (Emitter-Coupled Logic, или ECL) — использовалась в суперкомпьютерах и мэйнфреймах. Быстродействие ECL отчасти объясняется меньшим амплитудным диапазоном напряжения: разница между логическим «1» и «0» составляет всего 0,8 вольта. Однако ECL потребляет очень много энергии.

В матрицах логических элементов, выпускаемых компанией LSI Logic и используемых в Sun Dragon для управления кэш-памятью, оперативной памятью, вводом-выводом и шиной SBus, применялась технология CMOS. К сожалению, из-за большого амплитудного колебания напряжения между логическим «1» и «0» (5 вольт) возникали отраженные волны, которые ограничивали рабочую скорость шины. Билл Ганнинг решил сотрудничать с LSI Logic, чтобы перевести входные и выходные транзисторы матриц логических элементов, используемых в Sun Dragon, с логического напряжения TTL на логическое напряжение ECL. Так появилась новая технология транзисторной логики. В знак уважения к Ганнингу мы решили назвать её «транзисторной логикой Ганнинга» (GTL). Два года спустя IEEE стандартизировала эту технологию, сделав её доступной для всех.

Попутно отмечу, что, поскольку в проекте «Sun Dragon» широко использовались крупные микросхемы матриц логических элементов компании LSI, LSI направила молодого и энергичного менеджера по прикладной инженерии для оказания помощи проекту «Sun Dragon». Этого менеджера звали Хуан Жэньсюнь (Jenson Huang). Наше знакомство в начале 90-х годов положило начало нашей профессиональной дружбе, длившейся более двадцати пяти лет. Да, этот самый Хуан Жэньсюнь — основатель и нынешний генеральный директор компании NVIDIA.

«Ло» проекта «Sun Dragon»

Благодаря Юан-Шан Гестинару — нашему руководителю, консультанту и партнеру по обсуждению — научно-исследовательские и опытно-конструкторские работы над «Shengyang Long» ведутся по четко структурированной схеме. Мы осознаем масштаб этого проекта — это крупнейший системный продукт, когда-либо созданный компанией Shengyang, — и понимаем, что модульная архитектура, совершенно новая шина с разделением циклов, а также инновационная технология ввода-вывода GTL представляют собой смелые и весьма рискованные решения. Нам необходимо соблюдать строжайшую инженерную дисциплину и, там где это возможно, делать консервативный выбор, чтобы сбалансировать риски.

Например, в связи с быстрым развитием технологий DRAM в плане плотности и производительности, особенно с учётом длительного срока службы серверов, чипы памяти в то время не устанавливались непосредственно на материнскую плату, а на ней размещались разъёмы для установки вставных модулей DRAM. Такие модули, в которых чипы DRAM размещались по обеим сторонам небольшой тонкой печатной платы, назывались DIMM (Dual Inline Memory Module — двухрядный модуль памяти с прямолинейным разъёмом). Из-за ограничений, связанных с площадью контакта, необходимой для, и размером разъема, количество медных контактов по краям платы DIMM, соприкасающихся с внутренними зажимными пружинами разъема, было весьма ограниченным.

Поскольку эти медные контакты являются единственным каналом связи между логикой материнской платы и логикой DIMM, они представляют собой ценный ресурс. Однако мы специально спроектировали систему таким образом, чтобы соответствующие выводные и вводные медные контакты по обеим сторонам DIMM передавали одинаковые сигналы. Такой подход сократил количество доступных входных и выходных сигналов вдвое, но если пружина на одной стороне разъема ослабла и не могла обеспечить надёжный контакт, другая сторона по-прежнему могла обеспечить правильное соединение цепей, что придавало системе отказоустойчивость. Как только появились прототипы DIMM «Sun Dragon», я часто носил один из них в кармане рубашки. В течение двух лет, предшествовавших выпуску продукта на рынок, мне приходилось несколько раз в неделю проводить презентации для приезжающих клиентов Sun Microsystems, знакомя их с готовящимся к выпуску SunDragon. Во время презентаций я всегда доставал этот модуль DIMM из кармана пиджака и показывал его гостям в качестве доказательства того, что при разработке SunDragon мы уделяли внимание мельчайшим деталям. Клиентам это явно нравилось. Спустя много лет один из клиентов действительно признался мне, что они купили продукт исключительно из-за моего жеста. Клиенты — люди проницательные. Они терпеливо выслушивают рекламные речи маркетологов, но доверяют словам инженеров.

Чтобы ещё больше укрепить команду, мы наняли Стимсона Хо (Stimson Ho), ветерана компании Amdahl, специализирующейся на производстве хост-компьютеров, который возглавил команду по технологии физической упаковки. Лео Юань (Leo Yuan), выдающийся инженер по целостности сигнала, пришёл к нам из команды IBM 3081. Наш эксперт по источникам питания Чин Чен (Chin Chen) — лицензированный инженер-электротехник штата Калифорния.

Что касается логического проектирования, то модульность системы заключалась не только в том, что вся система состояла из одного–десяти одинаковых системных плат и двух шин Dynabus для связи между ними,но и логика на системных платах также модулирована на модули ЦП/кэша, логику управления кэшем, логику управления памятью, массив модулей памяти DIMM и логику управления вводом-выводом, которые соединены между собой двумя линиями Dynabus, проходящими по плате. Вышеупомянутые три вида управляющей логики, а также управляющая логика S-Bus, совместно используемая двумя группами логики управления вводом-выводом, реализованы на основе микросхем LSI с большими матрицами логических элементов. Каждая группа по проектированию матриц логических элементов состояла из одного опытного проектировщика логических схем и одного младшего инженера. За проектирование всей системной платы отвечал увлечённый и талантливый инженер Джефф Прайс (Jeff Price). Джефф был первым сотрудником со стороны Sun Microsystems в команде Sun Dragon.

Как только этап разработки архитектуры и спецификаций проекта был завершён, начался этап детального проектирования. В отличие от традиционного подхода, при котором коллеги проверяют проекты друг друга, мы тестировали всю систему, состоящую из нескольких системных плат (а значит, с несколькими процессорами, несколькими модулями памяти и несколькими отдельными входами-выходами S-Bus), с помощью многоуровневого моделирования. Сначала группы разработчиков микросхем матриц логических элементов проводят тестирование с помощью инструментов моделирования, предоставляемых LSI Logic. Затем группа разработчиков системных плат проводит симуляцию с использованием модели всей системной платы, включающей все протестированные модели микросхем матриц логических элементов. Наконец, группа по моделированию всей системы под руководством главного архитектора Проди тестирует многопроцессорную систему, соединенную по Dynabus на задней панели. Мы проводили не только тестирование нормального функционирования, но и проверку экстремальных ситуаций, с которыми могли столкнуться отдельные части конструкции. Мы даже настаивали на том, чтобы все разработчики нашли способы обеспечить работоспособность своих решений в условиях, которые не должны были возникнуть.

Процессор SPARC, который должен был использоваться в Sun Dragon, назывался «Viking» и все еще находился в стадии разработки одной из команд подразделения процессоров, поэтому в тестах использовалась поведенческая модель (behavior model) этого процессора. В четырехпроцессорной системе Maxiray, разрабатываемой подразделением рабочих станций, также использовался тот же процессор «Viking».

Чтобы скоординировать совместную работу всех этих модулей и групп в рамках моделирования, мне понадобился подробный рабочий план и график, который я мог бы показать как себе, так и всей команде. Именно тогда мне пригодился навык, который я приобрел, работая в «Сайчжун». В «Сайчжун» использовали несколько компьютеров Apple Macintosh в качестве общего сервера для хранения графических файлов и документов. В комплекте с Macintosh поставлялось приложение под названием MacProject. Оно использовало множество прямоугольников для обозначения модулей задач. На каждом прямоугольнике указывалось время выполнения задачи и даты начала и окончания. Прямоугольники задач соединялись прямыми линиями и стрелками, обозначая последовательность и зависимости (dependency). Руководители проектов могли легко отслеживать ход работы, критический путь в графике, а также взаимозависимости между задачами.

Когда компания «Сайчжун» закрылась, я купил один из Macintosh на распродаже по ликвидации и принес его домой. Я был уверен, что «MacProject» — лучший вариант для достижения моей цели. Каждый день после работы я начинал рисовать в «MacProject» график задач и стрелки зависимостей для проекта «Sun Dragon». Я нанес в диаграмму не только этап имитационного тестирования, но и весь процесс разработки продукта вплоть до даты первой поставки клиенту (First Customer Shipment, или FCS). Примерно через неделю весь рабочий план и график, включающие все задачи, даты, потребности в ресурсах и взаимозависимости, которые я только мог придумать, превратились в одну прекрасную большую диаграмму!

Если диаграмма слишком велика и не помещается на экране монитора целиком, Project позволяет просматривать её с помощью панорамирования или по уровням. На верхнем уровне отображаются только основные модули задач. Эти основные модули задач, в свою очередь, можно развернуть на следующем уровне на более детализированные модули. Я предпочитаю прокручивать диаграмму, так как это позволяет мне лучше видеть общую картину. Уровневое отображение, возможно, больше подходит для работы за компьютером или для руководства компании.

Поскольку я хочу, чтобы все члены команды могли увидеть этот план работы и график, я решил воспользоваться функцией увеличения всей диаграммы в проекте Майка. При печати на бумаге диаграмму можно увеличить так, чтобы люди могли видеть её толстые чёрные линии и крупный шрифт даже с большого расстояния. Для печати всего плана работы и графика «Восходящего дракона» в программе «МакПроект» потребовалось около восьмидесяти листов бумаги формата А4, причем каждый лист слегка перекрывал соседние листы по четырём сторонам.

Я принес эти восемьдесят распечатанных листов в компанию, занял пустой конференц-зал с большим столом для переговоров, обрезал ненужные части перекрытия на каждом листе, а затем склеил соседние листы. Готовая диаграмма рабочего плана и графика проекта имела длину двенадцать футов и высоту пять футов! Я выбрал коридор в центре офиса всей команды и прикрепил эту схему к стене. Каждый раз, когда какая-то задача выполнялась, я закрашивал соответствующий прямоугольник желтым фломастером. Теперь все члены команды, проходя по этому коридору, могли видеть ход выполнения всего проекта!

Многопроцессорный Sun Dragon был огромной машиной, и нам требовался очень большой объем симуляционных тестов. Для этого требовались значительные вычислительные мощности. Вскоре после того, как мы перешли к этапу симуляционных тестов, самый передовой на тот момент сервер Sun 420 только-только поступил в серийное производство. Первоначально объемы производства были весьма ограниченными. В связи с накопленным спросом стандартная процедура Sun заключалась в том, что первые выпущенные машины всегда поставлялись важным клиентам. Внутренние потребности инженерно-разработческого отдела обычно приходилось ждать шесть месяцев.

Однако проект Sun Dragon не мог ждать. Боевой дух команды был высок, а темпы разработки — высокими, но быстрый прогресс на этапе проектирования поставил наши возможности в области моделирования перед серьезным испытанием. Прежде чем передать микросхемы матриц ворот и печатные платы производителям для изготовления, нам предстояло провести огромный объем тестирования. Мы не хотели тратить много времени на отладку (debug) и переделку этого оборудования. Тщательное моделирование на раннем этапе — самый простой, эффективный и всеобъемлющий подход.

Несмотря на то, что я понимал: надежды не так уж много, я всё же заказал тридцать единиц из первой партии Sun 420. Если есть хоть малейшая надежда, я всегда делаю всё, что в моих силах, а удастся ли — решать уже Богу.

Пока я ждал результатов, однажды Эрик Шмидт, тогдашний вице-президент по инженерным вопросам, внезапно, без предварительной договоренности, пришёл с инспекцией в подразделение Sun Dragon. Возможно, вы слышали об этом Эрике Шмидте — позже он много лет проработал генеральным директором и председателем совета директоров Google.

Когда мне сообщили, что Эрик пришёл, я поспешил выбежать из офиса. Он сказал, что просто хочет прогуляться и осмотреть этот отдел. Сопровождая его, я кратко рассказал, чем сейчас занимается наша команда. Конечно, я также естественным образом упомянул о проблеме, связанной с отсутствием возможностей для имитационного тестирования. Когда мы проходили мимо коридора, где были вывешены планы проектов и графики работ, он обратил на них внимание. Он спросил меня, что это такое, и я ему объяснил. Я заметил, как его лицо просветлело. Полагаю, поскольку почти все проекты по рабочим станциям Sun были небольшими — команды насчитывали менее десяти человек, а время разработки не превышало одного года — он, вероятно, никогда раньше не видел такой дисциплины в выполнении графиков.