После ухода Менделя Розенблюма из VMware в компании не стало и его уникальной должности «главный ученый», поэтому Стивену Херроду достался менее громкий пост старшего вице-президента по исследованиям и разработкам и технического директора VMware. Назначение Херрода на этот пост выглядит вполне логичным, он давний соратник и ученик Розенблюма, был его аспирантом в Стэнфордском университете, а в 2001 году, через три года после основания VМware, стал сотрудником компании, где возглавлял группу, разрабатывавшую гипервизор ESX. Как же небольшой группе не слишком увлеченных предпринимательством людей удалось создать одну из самых быстро прогрессирующих высокотехнологичных компаний?
Расскажите об истории ваших первых проектов с Менделем Розенблюмом, как все начиналось?
Мендель был руководителем моей диссертационной работы, и я остался в той самой возглавляемой им лаборатории, сотрудники которой образовали ядро первого состава VMware, а четверо из них плюс Дайана Грин стали ее учредителями. Плавный переход из науки в бизнес возможен благодаря антрепренерскому духу, который господствует в Кремниевой долине вообще и в Стэнфорде в частности. Условия позволяют даже таким совсем не ориентированным на бизнес людям, как Розенблюм, создать компанию, разумеется если есть продуктивная идея. Однако путь от идеи до компании занял более десяти лет.
Чем же были заняты эти годы?
Должен заметить, популярное сегодня слово виртуализация возникло в нашей среде не сразу, поначалу мы ставили задачу несколько иначе – мы просто хотели, если можно так сказать, создавать аппаратное обеспечение из программного. Тогда в университетах для анализа новых конструкций компьютеров было очень модно использовать разнообразные методы имитационного моделирования, и у нас возник вопрос, а почему бы не пойти дальше и не построить программный конструктор, на котором можно было бы отрабатывать модель будущего компьютера, непосредственно выполняющего прикладное ПО? Ответ на этот вопрос с интервалом в несколько лет воплотился в двух проектах – SimOS и DISCO. Сегодня мы назвали бы SimOS гипервизором
Type 2, эта ОС работала поверх ОС IRIX, установленной на многопроцессорном сервере SGI, – данная работа описана в статье «Complete computer system simualation: The SimOS approach», датированной 1995 годом. В ней система SimOC названа целевым аппаратным уровнем, реализующим все основные узлы будущего компьютера. Лично моя научная работа была связана с созданием именно этой системы.
Разрабатывая ее, мы хотели избавиться от недостатков известных нам систем моделирования, которые имитировали поведение кодов пользовательской программы, а не комплекса программа плюс операционная система, что порождало недостаточную точность моделирования и невозможность достоверно воспроизвести условия работы приложений, сильно связанных с ОС, например СУБД. Исходя из этого мы построили SimOS как среду, способную моделировать всю вычислительную систему в комплексе, включая и приложения, и операционную систему. SimOS можно рассматривать как прослойку между железом и целевой операционной системой. Надо сказать, что тогда мы впервые использовали слово host для операционной системы и аппаратной платформы, на которых работает SimOS. Уже на первом этапе мы достигли многого из того, что пригодилось при создании современных гипервизоров, а именно скорости эмуляции и точности соответствия модели прототипу. SimOS создавалась как исследовательский инструмент, поэтому она предполагала несколько режимов исполнения: быстрый режим прямого исполнения и медленный с бинарной трансляций кодов, первый замедлял работу всего в два раза, второй — на порядок. Выбор того или иного режима зависел от решаемой задачи. Для будущей виртуализации важнее оказался первый.
В 1997 году завершился следующий проект, Disco, которым также руководил Розенблюм, а соавторами были Эдуард Буньон и Скотт Дивайн, они оба стали в последующем соучредителями VMware. С современных позиций Disco можно назвать монитором виртуальных машин, и здесь задача звучала следующим образом: «Допустим, есть массив вычислительных компонентов, объединенных в архитектуру ccNUMA. Как распределить ресурсы этого массива между несколькими различными по своей природе приложениям?» Одно из возможных решений — монитор, способный поддерживать некоторое количество виртуальных машин. Сейчас в vSphere, по существу, развивается эта же идея, она стала особенно актуальной с появлением облачных вычислений. Но тогда мы были чрезвычайно робки в высказывании по сути революционных идей, мы видели разрыв между возможностями масштабирования операционных систем и компьютеров, хотя уже тогда появлялись аппаратные платформы, насчитывающие десятки и сотни процессоров, а системное ПО с трудом справлялось с необходимостью предоставить эти ресурсы пользователям. Операционным системам не хватало того, что сейчас мы называем способностью к масштабированию, нам было ясно, что попытка доработать очередную ОС до уровня новой платформы приводит к необходимости выполнить большой объем работ, а сами системы становятся слишком сложными. И мы предложили альтернативный подход к конструированию программного обеспечения для этих больших компьютеров, сейчас их можно было бы назвать облаками. Вместо того чтобы каждый раз переделывать операционную систему, не лучше ли вставить между оппозиционной системой и аппаратным обеспечением промежуточный уровень, который будет выполнять функции монитора виртуальных машин, над каждой из которых может работать обычная (потребительская, commodity) операционная система? Здесь просматривается аналогия с гипервизором Type 1. При таком подходе мы решаем не только прямую задачу обеспечения масштабируемости без увеличения сложности, но и сохраняем потребительские ОС, что гарантирует совместимость с существующими приложениями. Уже тогда было понятно, что попутно решается множество иных проблем, например, связаннная с надежностью. Сегодня показатели надежности виртуальных систем выше, чем у мэйнфреймов, но тогда представления о надежности связывали исключительно с аппаратной архитектурой.
По сути, вы говорите о динамических ЦОД, об облаках, но описываемые события происходили более десяти лет назад. Эти работы явно опережали время, и все же первый успех VMware принесли не они, а более простые и прагматичные вещи, связанные с виртуализацией архитектуры x86. Вашему коллективу пришлось на несколько лет отложить работу с многопроцессорными конфигурациями и обратиться к обратной задаче – как разделить ресурсы одного процессора между несколькими приложениями.
Обращение к x86 — это отчасти удача, отчасти закономерность. Мы знали все сложности, связанные с виртуализацией этой архитектуры, но в то же время видели ее потенциал для будущего и владели технологиями бинарной трансляции, которые иначе как посредством массового процессора перевести из научных исследований в бизнес невозможно. Конечно же мы не могли предусмотреть того фантастического роста производительности и популярности x86, которые мы наблюдаем сегодня. В этом отношении нам повезло, но мы рисковали, и риск оправдался.
Итак, вы оставили многопроцессорные системы и сделали спасательный круг для x86, ведь откровенно архаичная архитектура, созданная для ПК, обрекала серверы на работу с чудовищно низким КПД. Как тут не вспомнить аргументы сторонников идей RISC и Unix, совершенно справедливо критиковавших Wintel, но на их несчастье в те времена острота проблемы энергопотребления и дороговизны управления не достигла нынешней остроты. И тут приходите вы, и поднимаете этот коэффициент в разы и тем самым консервируете x86 на десятилетия вперед.
Да, мы изрядно помогли Intel и AMD в их противостоянии с RISC-процессорами, которые лучше адаптированы к тяжелым нагрузкам. Мы и сейчас делаем ставку на x86, поскольку наблюдаем миграцию на эти процессоры с RISC. За последние годы виртуализация процессоров стала двухсторонней – Intel и AMD делают очень много со своей стороны, и сегодня издержки производительности, связанные с виртуализацией, пренебрежимо малы. Кроме того, эти компании внесли свой вклад в повышение надежности виртуализации, например включили контроль за памятью.
В деятельности VMware есть заметная специфика: предлагая новые решения, способствовать сохранению старого, не так ли?
В целом да, мы за сосуществование революционных и эволюционных решений, никогда нельзя забывать о накопленном багаже приложений, что-то радикально новое можно внедрить там, где нет груза старого, в этом специфика нашей отрасли. Заметную сложность составляет врожденно плохая масштабирумость приложений: есть предел, примерно четыре-восемь процессоров на приложение. Мы можем делать более мощные виртуальные машины, совмещающие в себе несколько процессоров, но этот предел преодолеть сложно. Тем не менее производительность процессоров так или иначе растет, и сейчас главная проблема не в обеспечении мощностью каких-то исключительных по своей нагрузке приложений, а в распределении имеющихся ресурсов между большим числом приложений. Часто решение состоит в том, что приложение надо делить на части, скажем не перегружать один Web-сервер, а запускать его несколько копий. В таком случае вам удастся снять большую производительность с одного и того же аппаратного сервера. В нашем багаже есть технологии, позволяющие разделять приложения на части и распределять их по множеству виртуальных машин.
Если следовать этой логике, то в VMware произошел возврат от виртуализации отдельного сервера к виртуализации их набора?
Сегодня в центре внимания VMware vSphere 4, работа над этой облачной операционной системой началась давно, и она унаследовала в том числе то, что было сделано для SimOS и DISCO, но ее прямой предшественницей является VMware Infrastructure 3 (VI), на ней мы отработали основные функции. В работе над vSphere 4 мы кооперировались с рядом крупных производителей, прежде всего с Cisco и особенно в связи с проектом Cisco Unified Computing System. В итоге я могу с уверенностью сказать, что у наших конкурентов есть хорошие технические решения, но все они ограничены рамками одного сервера, а в области виртуализации более крупных инфраструктур мы ушли вперед.
Виртуализацию чаще всего связывают с различного рода бизнес-приложениями, и обычно в стороне остаются высокопроизводительные вычисления, делает ли VMware что-нибудь в этом направлении?
Это очень важный вопрос, должен признать, что до сих пор мы не уделяли ему достаточного внимания, но в связи с возрастанием спроса на высокопроизводительные вычисления (High Performance Computing, HPC) мы меняем свои позиции. Сейчас начинаем взаимодействовать с компаниями из финансового сектора и с академическими учреждениями, которым требуется решать задачи моделирования и анализа. Мы взаимодействуем с поставщиками программного инструментария для HPC, например, совместно с компанией Platform Computing мы построили виртуальный кластер Virtual Computing Cluster, представляющий собой динамическую инфраструктуру, управляемую системами Platform VMO и VMware Infrastructure. Решение позволяет «отвязать» выполнение задачи от определенного физического узла, поэтому обладает заметно большей гибкостью, чем традиционные решения по управлению кластерами, отсюда более эффектное использование имеющихся ресурсов. Еще одно преимущество виртуальных кластеров проявляется для задач, выполняющихся в течение десятков часов. Если узлов много, то нельзя исключить вероятность выхода из строя одного из них, и обычно возобновление исполнения с какой-то контрольной точки требует восстановления всей аппаратной инфраструктуры, на что уходит время, а в нашем случае достаточно изменить распределение нагрузок между узлами. Мы добавляем интеллект к HPC. А вообще надо признать, что заманчиво было бы иметь некоторую универсальную инфраструктуру, способную выполнять любые нагрузки, будь то сервисные или HPC.
Стандартизация в вашей области еще очень молода, а стандарты и инновации нередко противоречат друг другу, но без них не обойтись...
Распространение специализированных виртуальных машин (software appliance), как формы распространения приложений, стимулирует стандартизацию. На первый взгляд все выглядит заманчиво, создатель оформляет приложение как готовую машину, а пользователю остается только ее загрузить и выполнить. Однако преимущества этой схемы проявятся только тогда, когда между всеми участвующими в процессе сторонами будет достигнуто соглашение о стандарте. VMware лидирует в работе над Open Virtualization Format (OVF), в создании которого также принимают участие Microsoft, HP, IBM, Dell, Citrix и общественная организация Distributed Management Task Force (DMTF). Второй инициативой в области стандартизации, стимулированной VМware, является DMTF Open Cloud Standards Incubator. Инкубатор — это шаг по обеспечению согласования между несколькими типами облаков, конечная цель состоит в открытии пользователю возможности выбора места для функционирования специализированных виртуальных машин, это может быть локальное частное облако или внешнее облако, поддерживаемое поставщиком услуг.
Ваше мнение по поводу виртуализации десктопов?
Виртуализация — это не просто возможность заменить логическим устройством физическое, а создание устройств нового качества, например сплавов. До сих пор говорят о «дилемме десктопов», рассматривая отдельно тонкие и толстые клиенты. Толстый позволяет выполнять на месте широкий набор приложений, но не удобен в обслуживании, требует больших трудозатрат и, самое главное, опасен, открыт вредоносному ПО и оставляет большие возможности для действий нелояльных пользователей. Тонкий клиент дешев, безопасен, лишен большинства недостатков толстого, но также и лишен его основных достоинств. Благодаря виртуализации мы можем на одном рабочем месте собрать лучшие качества обоих, создавая вполне безопасные мобильные клиенты, которые могут быть использованы не только в производственных, но и в личных целях. При этом безопасность корпоративной системы обеспечивается не бесконечным количеством систем информационной безопасности, а самой природой клиента, он не сможет нанести ущерба ни сознательно, ни бессознательно. Но только лишь десктопами дело не ограничивается, мы сможем распространить технологии виртуализации и на новые типы устройств: смартфоны и смартбуки, сейчас мы активно работаем над созданием гипервизора Type 1, работающего на «голом железе» процессора от ARM.
Что наиболее важно в виртуализации ЦОД?
Во-первых, следует назвать виртуализацию систем хранения, успехи которой позволяют придать виртуальному ЦОД более высокое быстродействие, эффективность и отказоустойчивость. Открывается возможность автоматизировать установку соответствия между виртуализационной платформой и физической инфраструктурой систем хранения, упростить все виды операций в системах хранения и поднять коэффициент их использования. В качестве примера можно привести решения, поддерживающие работу с массивами для типичных операций, выполняемых над виртуальными машинами, таких как репликация и миграция. Во-вторых, актуальной становится виртуализация «тяжелых» и наиболее ответственных приложений, она поддерживается сочетанием аппаратных и программных решений. Технологии Intel Extended Page Tables (EPT) и AMD Rapid Virtualization Indexing (RVI) решают проблемы приложений с большой нагрузкой на память и высокопроизводительных вычислений. Этому же способствует возможность заказывать приложения в готовом для исполнения виде, то есть в форме специализированных виртуальных машин. И третье, оркестровка ресурсов географически разделенных виртуальных ЦОД, позволяющая глобальным компаниям рассматривать ресурсы всех их ЦОД как один общий пул. Самый яркий пример – глобальный ЦОД British Telecom, представляющий собой единую облачную инфраструктуру, где можно балансировать нагрузками, используя центры, размещенные в Северной и Южной Америке, Великобритании, Европе, Азии и Австралии. На уровне пользователя это означает возможность «возить за собой» свой виртуальный десктоп по всему миру, на уровне предприятий – выбирать места с меньшей стоимостью энергии, автоматически решая задачу восстановления после аварийных ситуаций.
Какие направления развития виртуализации вы считаете важными в будущем?
Безусловно, виртуализацию ЦОД, но в целом мы идем к тому, что виртуализованным будет все, от простейших устройств до облаков, в перспективе виртуальными станут 100% приложений, и, когда это случится, люди прекратят говорить о виртуализации, она станет для них совершенно естественной. Лет восемь назад это прозвучало бы как шутка.
