Статьи

Hotmail: Unix to Windows

Этот текст является попыткой литературного перевода одной очень интересной статьи:
Hotmail: Unix to Windows. http://www.securityoffice.net/mssecrets/hotmail.html

Перевод .com сайта с ОС Unix на MS Windows.

Содержание
Краткий обзор.
Обзор проекта.
Критические особенности Hotmail как .com сайта.
Преимущества Unix.
Проблемы Windows.
Сильные стороны Windows.
Выбор архитектуры Hotmail.
   Ограничения проекта.
   Сохранение процедуры инсталляции.
   Переход к ISAPI.
   Технология распределения нагрузки.
Создание, освоение и инсталляция системы.
   Установка и конфигурирование ОС.
   Конфигурирование IIS.
   Настройка и "закаливание" системы.
   Использование Active Directory.
Установка приложений и обновления ПО.
   Способы обновления ПО.
   Техника обновления ПО.
   Intellimirror.
   Формат и механизм распространения ПО.
Мониторинг и ведение журналов.
   Центр сетевых операций.
   Автономный мониторинг.
   Ведение журналов.
Специальное обслуживание.
Работа над администраторами Unix.
Выводы.

Краткий обзор.

Назад к содержанию

В этом документе обсуждается способ перевода работы web-сервера Hotmail с ОС Unix на Windows 2000, а также причины использования конкретных технологий. Основное внимание здесь будет уделено планировщикам, разработчикам и системным администраторам. Цель данного документа - проиллюстрировать развертывание Windows 2000 в подобных проектах. Все технологии будут обсуждаться как с учетом человеческих факторов, так и с точки зрения используемого программного обеспечения.
Первые результаты преобразования, которое ограничилось web-серверами, образующими внешний интерфейс показали:

• Windows 2000 имеет большую пропускную способность, чем Unix.
• Windows 2000 имеет несколько большую производительность, чем Unix.
• У Windows 2000 есть потенциал, пока не реализованный, стабильной индивидуальной системы, эквивалентный стабильности Unix. Технология распределения нагрузки обеспечивает ситуацию, при которой пользователь получает услуги на том же уровне стабильности, что и до преобразования.
• Дальше будет показано, что хотя базовые компоненты Windows 2000 и позволяют поддерживать работу сервисов, их административная модель будет плохо приспособлена для этой цели.

Наблюдения, приведенные здесь, относятся только к одному сайту. Потребуется большее исследование, чтобы показать, являются ли они точными.

Обзор проекта.

Назад к содержанию

Microsoft приобрела Hotmail в конце 1997 года. Основатель ресурса создал двухуровневую архитектуру на базе различных Unix систем.

• Внешний web-сервер был построен на базе систем с двумя процессорами Pentium в стоечном исполнении. На них запускался Apache под управлением FreeBSD. Такая конфигурация позволяла использовать бесплатное ПО.
• Внутренний файл-сервер был построен на серверах Sun Enterprise 4500 и ОС Solaris 2.6. Для хранения данных использовался RAID массив, доступ к которому осуществлялся по очень простому протоколу.
• Сервер входящей почты был построен на Sun Sparc 5 процессорах и взаимодействовал непосредственно с внутренним файл-сервером.
• Верификация имен пользователей и паролей осуществлялась на серверах Enterprise 4500.
• Директории пользователей были построены на PC под управлением Windows NT и SQL.

Перевод Hotmail на Windows является действующим проектом, в основе которого лежат несколько идей. Команда проекта надеялась максимально использовать существующее оборудование. На первое место ставились наилучшее развертывание новой системы и глобализация пользовательских сервисов. Microsoft не хотела отказываться от своих принципов в данном проекте. И наконец, полученный опыт в преобразовании системы было решено использовать как модель для будущих проектов по преобразованию Unix.

Первая часть преобразования системы, описанная здесь, ограничивалась внешним web-сервером. Необходимое оборудование было уже задействовано. Персонал, который осуществлял планирование и развертывание новой системы, был уверен в успешном завершении преобразовании системы.

Также существовало несколько ограничений на время проведения преобразования, которые, вероятно, являются типичными для интернет серверов:

• На Hotmail был установлен 8-ми недельный цикл обновления версий ПО. Это решено было оставить, кроме того, на этом настояли некоторые из партнеров.
• Необходимо поддерживать непрерывную работоспособность сервисов.
• Штат сотрудников был маленький, но возможностей для его расширения не было.

Особенности hotmail.com.

Назад к содержанию

Hotmail является хорошим примером большого Интернет-сервера. Он является одним из наибольших почтовых серверов на планете, поэтому необходимо осторожно проецировать его особенности на гораздо меньшие сайты, также неверными окажутся выводы, основанные на масштабировании ресурсов. Как было сказано выше, все внимание было сосредоточено на внешних web-серверах. Несмотря на то, что следующие комментарии также относятся и к серверам баз данных, они не будут отдельно обсуждаться далее.

1. Специализированное, хорошо управляемое приложение. Приложение под Unix представляло собой набор CGI программ, которые обслуживали около 100 независимых URL. Этот набор программ был портирован в модуль ISAPI. Программы были написаны на С++. Это приложение находилось под контролем одной команды, которая полностью владела нюансами его архитектуры. Обновления программы происходили только при плановых обновлениях серверного ПО и установке "заплаток". Это ощутимо отличалось от сайтов типа www.microsoft.com, у которого есть огромное количество разработчиков и происходят непрерывные обновления.
2. Удаленное администрирование. Все сервера легко управляемы и могут обслуживаться контрактными работниками, также нет необходимости постоянного присутствия обслуживающего персонала около серверов. Сервера должны иметь средства самодиагностики и обслуживающий персонал должен иметь возможность управлять ими удаленно.
3. Максимально идентичные конфигурации оборудования. Это позволит описать плановые административные задачи, такие как обновление ОС и приложений, в виде скриптов, что позволит их выполнять быстро и без непосредственного участия оператора. У администратора не будет времени на плановое индивидуальное обслуживание каждого сервера. Механизм распределения нагрузки направит запрос пользователя по виртуальному адресу к одному из реальных серверов.
4. Затраты на содержание системы увеличиваются в геометрической прогрессии. Установка VGA монитора или второй сетевой карты на сервер или подключение к нему терминала, имеет достаточно низкую цену для одной машины. Но покупка нескольких тысяч подобных устройств требует уже серьезных инвестиций и тщательного согласования.
5. 100% доступность. Большой Интернет сайт должен быть доступен круглосуточно все 365 дней в году. Более того, он должен быть все время готов к максимальной нагрузке. Загрузка Hotmail в течении дня колебалась в зависимости от активности пользователей в различных часовых поясах США, но в остальное время нагрузка сильно не изменялась, поскольку у Hotmail большое количество пользователей по всему миру.
6. Синхронный upgrade. Обновление серверов должно происходить практически одновременно, иначе пользователь в течении одной своей сессии может заметить различие между обновленными и не обновленными элементами системы. Типичное взаимодействие пользователя с сервисом заключается в нескольких кликах мышью, т.о. не выйдет ничего хорошего, когда переход по ссылкам приведет к исполнению кода от разных релизов. Эта проблема может выражаться как в изменчивости интерфейса, так и в неработоспособности новых опций.
7. Полное отсутствие персональных компьютеров и аккаунтов. Все компьютеры должны быть защищены как физически, так и электрически. Вообще говоря, в то время, когда администратор выполняет какие-либо действия на сервере или на сервере выполняется плановая задача, им даются полные административные права. Это повышает опасность, но уменьшает вычислительную мощность, необходимую для сопровождения и синхронизирования учетных записей.
8. Удаленный мониторинг. Слежение за производительностью осуществляется с помощью опроса серверов или через автоматически генерируемые отчеты, мониторинг сервера производится с помощью дополнительной сетевой карты. В случае Hotmail существовало достаточное количество резервных сетевых каналов для организации мониторинга без ущерба общей производительности.
9. Нет ограничений для роста архитектуры узла. У Интернет сайтов всегда возможно расширение. В начале, ограничения выбранной архитектуры кажутся недостижимыми, но в один прекрасный момент, приходится их преодолевать, используя доступные ресурсы. Hotmail "вырос" от 9 миллионов учетных записей в момент покупки его Microsoft до 100 миллионов в июле 2000 года без капитальных изменений в аппаратной и программной архитектурах.

   Последние 4 пункта тесно связаны с Hotmail, но автор надеется, что они отражают так же и проблемы рынка в целом.

10. Масштабируемость. Hotmail построен из нескольких модулей, составные части каждого из которых могут быть неограниченно масштабированы. На этом этапе проекта было решено сосредоточиться на внешнем интерфейсе: серверах, которые будут управлять всеми пользовательскими интерфейсами и частью системных. Среди серверов - большинство (которые представляли внешний интерфейс) исполняли код, с которым непосредственно работали пользователи. Эта часть сервером стала первой на этапе перехода на Windows 2000. Эти компьютеры представляют собой одноплатные х86 РС, достаточно мощные для работы Apache под FreeBSD 3.0. К счастью, их мощности достаточно для работы на них Windows 2000.
    На Hotmail также присутствовали несколько серверов, содержащих только статический контент, перевод которых не должен вызвать проблем после перевода на Windows внешних серверов. Их администраторы использовали те же методы управления, что и на серверах, предоставляющих внешний интерфейс. На серверах со статическим контентом также работала FreeBSD совместно с сервером boa, который оптимизирован для обслуживания статического контента.
11. Консерватизм в конфигурировании. На Hotmail используется около 3000 компьютеров, предоставляющих внешний интерфейс, все они имеют идентичную аппаратную конфигурацию. Абсолютно одинаковая конфигурация серверов очень важна для администрирования, поскольку клонирование устоявшейся конфигурации гораздо предпочтительнее, чем настройка новой модели.
    Это так же относится и к программному обеспечению. Необходимость обеспечивать бесперебойный сервис [1] накладывает на проект ряд ограничений: разработчики должны постоянно совершенствовать программную базу, и очень мало ресурсов остается на переработку базовых конструкций. Более того, многие модули сайта разрабатывались независимо, создавая основу для внутренней стабильности сайта.
12. Проектирование стабильной системы. В сущности, время бесперебойной работы системы и время отклика системы являются критическими величинами. Это достигается некоторой избыточностью системы и очень надежным оборудованием, распределяющим нагрузку (Cisco Local Director). Local Director это еще один модуль позволяющий масштабировать систему.
13. Контролируемые и понятные системы. Факт, что в Unix администратор может легко убедится в том, что в системе не запущено лишних сервисов. Это теоретически позволяет поднять производительность системы, а так же позволяет убедиться, что отсутствуют открытые порты TCP/IP или UDP, через который сервер может подвергнуться атаке. Подобная прозрачность является внутренним свойством Unix, но в то же время это происходит из-за глубокого понимания администратором всей системы.

Системы, которые управляются удаленно, оказывают большое влияние на способ администрирования системы. Такие системы предполагают, что любое управление в них происходит удаленно (с помощью telnet или терминального сервера), таким образом невозможно определить какая информация предается удаленно, находясь непосредственно у консоли компьютера [2] и, даже, BSOD будет невидим. Кроме того, удаленное управление подразумевает, что непосредственный приход человека к компьютеру может вызвать дополнительные расходы. Hotmail обслуживается контрактными работниками, работа которых в основном ограничивается заменой вышедших из строя серверов и их перезагрузкой при необходимости, иногда возникает необходимость подключить монитор или клавиатуру к работающей системе, но это скорее является исключением.

Преимущества Unix.

Назад к содержанию

Можно сказать, правда не совсем корректно, что общий термин Unix описывает семейство операционных систем развернутых на множестве аппаратных платформ. Несмотря на то, что их внутренние архитектуры отличаются друг от друга, всевозможные реализации Unix с точки зрения конечного пользователя очень похожи за исключением некоторых мелких и порой досадных различий. На Hotmail использовались две Unix системы: FreeBSD, которая использовалась без всевозможных лицензионных отчислений, а ее исходный код является свободно доступным, и Solaris, работающая на аппаратной платформе Sun. Linux, еще один из вариантов Unix, на Hotmail не использовался.
Ниже рассмотрены особенности Unix (в частности FreeBSD) в свете проблем, которые могут возникнуть при преобразовании. Так же дальше полагается, что Apache является неотъемлемой частью решений на базе Unix, а IIS - решений на базе Windows 2000 Server.

1. Знание основ. Основатели этого предприятия, в целом, хорошо разбирались в одной из реализаций Unix (обычно это изучают в колледжах) и могли легко переходить от одной версии Unix к другой. При создании нового проекта, гораздо легче работать с известными системами, чем тратить время на изучение альтернатив.
2. Гарантированная стабильность. Ядро Unix и ее архитектура сформировали знаменитую стабильность Unix. Система, состоящая из нескольких тысяч серверов должна работать стабильно без необходимости перезапускать систему из-за сбоящего процесса. Для Windows 2000 сначала необходимо добиться устойчивости на таком же оборудовании, а затем убедить в этом остальных.
   Apache также проектировался больше в расчете на стабильную и точную работу, чем на повышенную производительность и большой набор возможностей.
3. FreeBSD бесплатна. Но присутствуют сопутствующие расходы (достаточно сложная настройка системы), правда, отсутствие платы за лицензию может сыграть решающую роль, особенно в начале проекта. Свободно распространяемые исходные тексты ОС позволяют с легкостью (или с большим трудом) вносить изменения в ОС исходя из локальных потребностей [3].
4. Простая минимизация. Типичный Unix-сервер обрабатывает одну задачу, не являясь при это рабочим ПК пользователя или разработчика. Очень просто ограничить список загружаемых системой сервисов. Более простая система является в тоже время более стабильной и гибкой.
5. Прозрачность. В Unix-системе просто узнать, какие процессы запущены в данный момент и почему. Несмотря на то, что синтаксис конфигурационных файлов может иметь как скрытый смысл так и быть абсолютно прозрачным, работать с конфигурационными файлами легко.
6. Текстовые файлы. Большая часть конфигурационных файлов, файлов журналов и т.п. имеет простой текстовый формат и достаточно малый объем. Хотя это косвенно может повлиять на производительность (обычно этого не происходит), текстовые файлы удобны тем, что для их обработки администратору не требуется мощные инструменты. В частности, один текстовый редактор может применяться для анализа всех системных журналов и сообщений об ошибках.
7. Мощный и доступный скриптовый язык. Опять ключевыми являются простота и надежность Unix. В течении многих лет в Unix развился мощный набор простых системных функций и скриптовый язык командной строки (shell), которые легко справляются с ежедневными административными задачами и способны внести изменения в функционирование системы. Shell нельзя назвать языком программирования (он гораздо скромнее VBScript или JScript). Это может показаться недостатком, но операторы - не программисты и изучение ими структурированного языка программирования может оказаться проблематичным. Скрипты, которые составляют из исполняемых модулей конвейер, легко составлять, постепенно наращивая его и экспериментируя. Даже опытные администраторы Hotmail предпочитали использовать специальный скриптовый язык (с помощью CMD) вместо более мощных объектно-ориентированных скриптов.
   С другой стороны, Perl (еще один язык программирования, который создавался большой группой разработчиков) больше похож на язык программирования, чем на скриптовый язык. Он часто используется для регулярных и автоматизированных задач, которые могут разрабатываться и отлаживаться ведущим административным персоналом, имеющим большой опыт в программировании.

Проблемы Windows.

Назад к содержанию

Описанные выше сильные стороны Unix одновременно являются слабостями Windows. Однако необходимо отметить некоторые специфические особенности Windows.

1. GUI. Серверные продукты Windows 2000 разработчики продолжают создавать, думая о десктопе. В Windows 2000 содержится слишком много функций, которые сложно или практически невозможно реализовать в командной строке.
   Почему это важно? Есть несколько причин:
   • Операции в GUI невозможно описать в скрипте. При большом количестве серверов непрактично использовать GUI для проведения процедур инсталляции или плановых работ.
   • Текстовые операции более универсальны, используя их администратор может больше сделать для системы (как плохого так и хорошего), чем при использовании ограниченных и заранее спроектированных методов GUI.
   • В случае Hotmail, был создан канал безопасности, в котором использовался интерфейс с командной строкой.
   • Использование GUI, в целом, скрывает от администратора реальное взаимодействие с системой. Операторам Unix нравится чувство полного контроля над системой, которое происходит от их возможности непосредственно конфигурировать систему.
   • Работа с GUI по медленной линии больше тормозит, чем приносит пользу. Однако, это не так важно, поскольку может проявится только при работе администратора с сервером через обычный модем.
   Правда, существует набор не-GUI административных программ, поставляющиеся с Windows 2000 и ее Resource Kit. Проблема в том, что этот набор инструментов производит впечатление какого-то случайного, бессвязного и несовместимого набора программ. Как будто они были написаны для решения каких-то текущих проблем, они содержат стилистические противоречия и мало функциональны.
2. Сложность. Windows сервер - это хорошо продуманная и детально разработанная система. Она хорошо подходит для таких специфических задач, как web-сервер, однако Windows содержит много сервисов, имеющих сложную взаимную зависимость, поэтому не всегда ясно, какой из них можно убрать, а какой - нет, не нарушая при этом стабильности системы.
3. "Темная лошадка". Некоторые параметры, управляющие системой скрыты и получить доступ к ним сложно. Типичный пример - метабаза. Проблема в том, что это заставляет администратора нервничать, поскольку в системе, выполняющей одну функцию, он хочет понимать все возможные нюансы работы системы при внесении изменений в конфигурацию.
4. Использование ресурсов. Известно, что Windows требует более мощный компьютер, чем Linux или FreeBSD. На практике это не столь существенное ограничение. Когда вы создаете большое предприятие, вы используете небольшое количество по-настоящему мощных компьютеров. PC, используемые на Hotmail, хорошо совместимы с Windows, и ресурсы, необходимые для работы базовых функций Linux или Windows, требуются практически одинаковые. Большую часть времени компьютер выполняет только программный код, а большая часть ресурсоемких функций не выполняется.
5. Размер образа. Команде не удалось создать образ Windows менее, чем 900Мб. Это связано с тем, что Windows содержит большое количество взаимосвязанных частей, вынести которые за рамки резервной копии невозможно. Свободное дисковое пространство не являлось проблемой, но большую роль играло время, необходимое для создания резервной копии систем тысяч серверов. Для сравнения, размер резервной копии FreeBSD на такой же конфигурации составлял несколько десятков мегабайт.
6. Ожидаемая перезагрузка. Работа с Windows все еще требует слишком большого количества перезагрузок. Иногда они не являются необходимыми, но операторы перезагружают систему чаще, чем тратят время на устранение неполадок. Например, возможно завис сервис и гораздо удобнее перезагрузить систему, чем потратить время на выяснение причины его зависания. В Unix наоборот, администратор способен быстро выявить упавший процесс и просто перезапустить его, в этом ему помогает большая гибкость Unix и небольшое количество взаимосвязанных процессов. Некоторые перезагрузки требуются после инсталляции приложений, но они не являются необходимыми.
7. Стоимость лицензии. Как уже говорилось выше, стоимость лицензии Windows ПО вызывает большие размышления при переходе от свободно распространяемого Unix. Хотя Hotmail получал ПО бесплатно, как подразделение Microsoft, факт стоимости лицензии необходимо учесть для создания модели преобразования, которая может быть применена другими клиентами.
   • Использование Server, а не Advanced Server (поскольку для работы не требуются особенности Advanced Server).
   • Неохотное использование сервисов для Unix и Interix для получения доступа к функциям, которые не адекватно реализованы в Windows. В дальнейших выпусках Windows эти возможности должны быть реализованы, что сделает использование Unix и Interix ненужным.
   • Никто из бизнес аналитиков не взялся определить будет ли выгода от преобразования ОС перекрыта стоимостью лицензий Windows.

Сильные стороны Windows.

Назад к содержанию

1. У Windows более развитая база ПО. Дистрибутивы Windows более комплексные, чем у Unix, используя их с умом (и знаниями), можно получить более эффективные решения. Например, IIS более настраиваемый, чем Apache.
   IIS и Windows обладают большим количеством настраиваемых параметров, чем Apache и FreeBSD. Проблема в том, чтобы администраторы хорошо освоились с новой связкой ПО.
2. Инструменты для разработчиков, особенно Visual Studio, являются большим преимуществом. Даже до преобразования Hotmail на платформу Windows, разработчики Hotmail использовали Visual Studio на NT 4.0 для разработки и анализа ПО. После завершения первого этапа отладки, код перекомпилировался под Unix. В Unix, кроме инструментов разработчика Java, нет ничего подобного по мощности Visual Studio.
   Наличие лучшей платформы для разработки ПО также является хорошим стимулом для работы с действующим сайтом. В первые дни развертывания новой системы, было замечено, что некоторые процессы зацикливаются, забирая на себя все процессорное время. Используя Visual Studio, разработчики за несколько минут смогли обнаружить проблему с ПО. Используя инструменты Unix, этого сделать было бы невозможно.
3. Значительно лучшая инфраструктура мониторинга. В Unix есть только элементарные журнал событий и инструменты мониторинга производительности, что не может сравниться с мощной интегрированной системой журналов событий и возможностями монитора производительности.. В тоже время, системный мониторинг широко используется в работе, в частности, журнал событий является средством общения человека и системы, о чем будет рассказано ниже.
4. Лучшее распознавание аппаратуры. Настройка Unix на новом PC является сложной задачей, требующей глубокого понимания аппаратной архитектуры. Таким образом, задача развертывания системы на серии идентичных компьютеров будет легко решена.
5. Интернациональность. Программные инструменты, доступные в Windows и обеспечивающие создание локализованных решений, развиты гораздо лучше, чем в Unix.

Выбор архитектуры Hotmail.

Назад к содержанию

Ограничения проекта.

Назад к содержанию

Ограничения, описанные ранее (8-ми недельный цикл обновления ПО, необходимость постоянно поддерживать работоспособность сервисов и маленький персонал), оказывали ощутимое давление на разработчиков и административный персонал, поэтому было решено во время одного из циклов произвести смену платформы, не трогая при этом ПО. Это позволит разработчикам и тестерам сосредоточиться на специфических проблемах, вызванных сменой платформы. В ходе преобразования, будет использоваться общее для двух платформ ПО. Это означает, что пользователи, подключаясь к сервисам, которые работают на разных платформах, не заметят различий.
Те же соображения легли в основу решения не менять способ эксплуатации без особых причин - во-первых, потребовалось бы переобучение всего персонала; во-вторых, если вносить незначительные изменения, то возникшие проблемы будут так же незначительными.
И наконец, экономическое требование не увеличивать штат, повлекло за собой решение не изменять кардинальным образом архитектуру ПО.

Сохранение процедуры инсталляции.

Назад к содержанию

Была разработана методика удаленной установки ОС и набора приложений на сервер, и, таким образом, время перехода одной стойки с серверами (21 компьютер) к другой ОС составит порядка 20 минут. Главной целью проекта являлась воспроизводимость процедуры инсталляции новой ОС, также было бы желательно сохранение инфраструктуры, используемой для перевода серверов на другую ОС.

Переход к ISAPI.

Назад к содержанию

Основа ПО web-сайта содержит порядка 90 различных транзакций, каждая из которых соответствует клику мыши на самой web-странице. При использовании Apache, каждая транзакция реализовывалась как исполняемый модуль, используя CGI интерфейс, и исполнялась как отдельный процесс, принадлежащий Apache. Использование процессов для выделения общих транзакций было естественно для Unix.
Переходя к Windows, группа разработчиков решила не использовать CGI интерфейс для IIS. Создать новый процесс в Windows сложнее, чем в Unix. Вместо этого команда портировала CGI код на ISAPI, в котором транзакции обрабатываются кодом, который (в большинстве базовых реализаций) исполняется в самом процессе IIS.
Исполнение задач в процессе является более эффективным, чем их выполнение в виде CGI, поскольку в этом случае не требуются системные сигналы для создания процесса. Выше это было определено как сильная сторона Unix. Apache поддерживает подобные решения - эквивалентом фильтров ISAPI являются модули. Естественно, разработчики не стали понапрасну создавать модульную систему для Apache, чтобы затем от этого отказаться.
Переход от CGI к ISAPI был в основном автоматизирован при помощи фильтров, которые эффективно предоставляли CG интерфейс (используя потоки данных и переменные окружения) для исполняемого кода пользователей. Поскольку существующий код был написан грамотно и переменные окружения не использовались монопольно, основная часть перехода от CGI к ISAPI не потребовала существенного вмешательства программистов [4]. Вот некоторые части проекта, которые умышленно были переработаны программистами:

• Функции правописания, словаря и тезауруса были переписаны с использованием технологий Microsoft, использовавшихся в Office и Encarta. В Unix версии этих функций использовались исполняемые модули Мерриама Вебстера (Merriam Webster). Проверка правописания была существенно улучшена, что в свою очередь, позволило решить некоторые проблемы с содержимым словарей, к которым обращались пользователи.
• SMTP сервис IIS использовался для управления исходящей почтой вместо стандартного постового сервиса Unix.
• Антивирусная проверка вложений к письмам осуществлялась при помощи утилит McAfee, ранее использовалась версия для Unix, теперь - для Windows.

Наиболее сложной и ожидаемой проблемой при переходе к ISAPI явился отказ от основ CGI-архитектуры. "Утечки памяти", не закрытые файлы и т.п., ранее были незначительными проблемами, т.к. они автоматически устранялись при завершении CGI-процесса. Даже если и происходил сбой, то это вызывало появление неадекватной web-страницы только у одного пользователя, в то время как остальные части системы функционировали корректно.
В ISAPI, наоборот, модули разделяют ресурсы одного процесса, как и модули Apache. Это приводит к накапливанию утечек ресурсов, что может привести к падению отдельного сервера (но не к падению всего узла, благодаря механизму распределения нагрузки). В IIS существует возможность изолировать различные процессы, но команда разработчиков решила использовать модель, построенную на одном процессе для достижения максимальной производительности. Были приняты следующие меры:

• Использование отдельных областей памяти для хранения временных данных, которые очищаются при завершении web-транзакции.
• Во время тестирования фиксировались и устранялись "утечки" ресурсов.
• Был создан монитор состояния IIS, который перезапускал IIS при его падении.

Переход к ASP был бы необоснованным. Это потребовало бы полного переписывания кода приложения, не давая при этом ощутимой выгоды (на Hotmail, например, не использовалась инфраструктура WinDNA). Фактически, некоторые идеи и элементы ASP были использованы в проекте, в основном в качестве пользовательского контента, определяемого на основе файлов-шаблонов, которые имели вид ASP-файлов, но обрабатывались прежним интерпретатором. Одним из мотивов для использования синтаксиса ASP стало использование разработчиками инструментов Microsoft (например, для облегчения глобализации).

Технология распределения нагрузки.

Назад к содержанию

Hotmail много средств инвестировал в Cisco Local Director (LD), каждый web-запрос поступивший к LD распределялся среди реальных серверов. Hotmail решил и далее использовать LD, совместно с технологией распределения нагрузки Windows, поскольку существующая инфраструктура была "на месте" и ее переконфигурация не требовалась (что уменьшало цикл обучения персонала). Также LD хорошо вписывались в модель Hotmail - они позволяли назначать один виртуальный адрес 400 серверам, а каждый кластер Hotmail содержал 300 идентичных серверов.
Следующей большой проблемой стала потенциальная стоимость ПО. Хотя Hotmail использовал продукты Microsoft бесплатно, для полной картины необходимо учесть и возможную стоимость ПО. Использование технологии распределения нагрузки, предоставляемой Windows, требует использования Advanced Server, но Server предоставляет все остальные необходимые сервисы для Hotmail. Используя текущие цены на ПО, сравнительная цена ПО для 3500 серверов составит:

• Использование технологии распределения нагрузки от Microsoft (т.е. использование Advanced Server) - около 15 млн. $.
• Использование LD и Server - около 6 млн. $.

В эту стоимость не включено возможное расширение парка PC для поддержания работы технологии распределения нагрузки (а также административные задачи по распределению нагрузки) или планы Cisco по уменьшению в будущем цен на LD, используя при их изготовлении собственные коммутаторы.
С точки зрения такого большого узла как Hotmail, использование технологии распределения нагрузки от Microsoft, может нанести большой экономический урон, если не будет сбалансировано уменьшением расходов на администрирование и мониторинг системы. Возникает конкуренция на рынке по распределению IP нагрузки, что приводит к общему удешевлению. Цифры, приведенные выше, основаны на ценах середины 1999 года из расчета 17 тыс. $ на PС. Существующая система, в которой развернуто распределение нагрузки, вероятно, уже имеет необходимые инструменты для работы с ней, т.о. приобретение технологии распределения нагрузки от Microsoft должно быть хорошо обосновано экономически.

Создание, освоение и инсталляция системы.

Назад к содержанию

Установка и конфигурирование ОС.

Назад к содержанию

На каждом из нескольких тысяч серверов должны быть установлены новые ОС и ПО, причем этот процесс должен происходить без прерывания обслуживания клиентов и в очень короткое время. Требовался способ создание образа новой системы, а затем установки его. Также присутствовали некоторые специфические требования:

• Каждый сервер уже имел уникальное имя и свой IP адрес, т.о. новая система должна будет получить тоже имя и адрес. Использование статических адресов, по сравнению с DHCP, позволяет администраторам действовать наиболее гибко. Имя сервера соответствует его физическому расположению в кластере.
• Необходимо произвести преобразование удаленно.
• Необходимо предусмотреть возможность отката системы к FreeBSD, в случае нестабильной работы Windows.
• Время перезапуска ОС и сервисов должно быть минимальным.

Было рассмотрено и отброшено несколько вариантов. В основном, они не имели недостатков, но и не давали необходимых гарантий успешного завершения проекта. Вот некоторые из них:

• RIS может использоваться для автоматической установки образа на сервер в момент начальной загрузки машины. Минусами этого варианта являются: требуется непосредственный доступ к серверу (для установки загрузки по сети); требуется DHCP для установки IP адресов новой системы (DHCP не использовалось на Hotmail, поскольку для серверов использовались статические IP адреса). Невозможно предварительно установить имя нового сервера. И, наконец, RIS не позволяет удаленно устанавливать Server, несмотря на то, что это возможно.
• AppCenter разрабатывался именно для таких целей. Однако, изначально он был предназначен для небольших объемов. Также в AppCenter отсутствовали некоторые необходимые возможности для инсталляции и обновления ПО.
• Стандартная инсталляция ОС по сети. Поскольку в этом случае приходится каждый раз копировать все файлы, этот метод является чрезмерно медленным.

В итоге было решено оптимизировать известную технологию быстрого запуска ("kickstart"). Этот метод использует существующую на машине ОС для загрузки образа новой ОС, подготовленного при помощи утилиты sysprep, а затем запускается скрипт, который завершает конфигурирование ОС. Копирование образа происходит быстро, а послеинсталляционные процедуры - минимальны.

Конфигурирование IIS.

Назад к содержанию

Было подтверждено, что точное конфигурирование IIS является сложной задачей. Документация по метабазе (metabase) туманная, неполная и преподносит слишком много сюрпризов. Более того, система, созданная при помощи sysprep не содержит готовой к работе метабазы.
Следовательно, необходимо построить метабазу при помощи скрипта. Скрипты являются смесью исполняемых файлов, которые периодически вызывают утилиту mdutil, и специализированных частей кода (в этом случае - VBScript, поскольку подходил любой язык, поддерживающий COM). Скрипты запускались на одном из шагов послеинсталляционного конфигурирования системы.
Создание структуры метабазы, элементы которой должны быть установлены, и избавление от нежелательных элементов (например, деревья, определенные по умолчанию и администрация узла) явились наиболее сложными и подверженными неточностям частями проекта. Потребовался большой инженерный анализ. Основные улучшения требуются при взаимодействии метабазы с пользователями и при описании администраторами общих задач в виде скриптов.

Настройка и "закаливание" системы.

Назад к содержанию

Задача - получение наилучшей комбинации пропускная способность/производительность и защита системы от внешних атак. Это требует обратить внимание на следующие моменты:

• При конфигурировании системы отключаются все неиспользуемые сервисы, оставшиеся сервисы настраиваются на максимальную эффективность.
• Настройки Реестра - на производительность и безопасность.
• Настройки метабазы - на производительность и безопасность.

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

Использование Active Directory.

Назад к содержанию

Active Directory (AD) является ключевым дополнением Windows 2000, и пока трудно определить нужно ли использовать AD для Hotmail.

Пользователи в AD.

AD, как правило, используется для управления множеством пользователей и машин. В случае Hotmail, не было необходимости использовать AD для управления клиентами. Привилегии и ограничения для пользователей на Hotmail регулируется ПО, и нет необходимости устанавливать привилегии для пользователей в инфраструктуре Hotmail. Более того, на Hotmail происходит постоянное изменение множества имен пользователей (всего около 100 миллионов на июль 2000 г.), такое количество пользователей может не поддерживаться Windows 2000.
На узле присутствуют пользователи, но в другом контексте: учетные записи администраторов, которые используются для управления системой как людьми, так и при помощи скриптов. Однако, все администраторы были доверенными лицами для системы (поскольку они находились за firewall'ом), что позволяло входить в систему с полными административными правами. Это эквивалентно учетной записи root в Unix. Удобно разрешить администраторам использовать одну точку входа в систему для управления всеми серверами, а также централизовано управлять учетными записями пользователей, однако этим требованиям полностью удовлетворяет NT 4.0 NTLM.

Компьютерные системы в AD.

Есть сильный аргумент в пользу AD. AD интегрирована с DNS, и предоставляет администраторам возможность именовать машины любым удобным им способом.
Hotmail организован как набор кластеров, каждый из которых содержит несколько сотен серверов. Имена машин должны быть систематизированы. На практике, имена серверов в различных кластерах дублируются, поскольку уникальным именем будет полное имя сервера (каждый кластер является поддоменом). Это создаст проблему для AD, которая (видимо для совместимости с NetBIOS) не разрешает использовать одинаковые короткие имена внутри домена. Отказ от поддержки NetBIOS стал бы большим подарком от Microsoft.
Это на первый взгляд незначительное ограничение послужило поводом для отсрочки развертывания AD, которая в любом случае выполняла бы второстепенные задачи, не принося очевидной выгоды. Необходимость сохранить имя сервера в момент модернизации возникала для сохранения действующих механизмов администрирования и мониторинга. Существующие инструменты администрирования хорошо функционировали в новой системе и им не требовались для работы возможности AD. Ожидалось, что в дальнейшем администраторы разработают инструменты для работы с AD (например, возможность обращаться с запросом к серверу с неполным набором параметров (?)), но в настоящий момент в этом нет необходимости.
DNS сервис Windows, работая без AD, хорошую справляется с управлением нагрузкой, а так же легко взаимодействует с BIND сервером, работающим под Unix. Windows DNS использовался на узле для управления как внешними, так и внутренними именами.

Установка приложений и обновления ПО.

Назад к содержанию

Способы обновления ПО.

Назад к содержанию

Естественно требовать от web-ориентированного сервиса непрерывной работы, таким образом, что бы пользователь не замечал снижения работоспособности сервиса. Это не только вопрос престижа, даже потеря работоспособности на несколько минут в течение месяца может привести к потере контроля над производимыми статистическими измерениями (Hotmail публикует время непрерывной работы узла).
Есть решение, но с одним слабым местом: разместить сервера за оборудованием, производящем распределение нагрузки, что позволит не запускать сервисы на серверах, требующих вмешательства персонала. Задача - как можно дольше поддерживать сервера в работоспособном состоянии. За исключением обновления самой ОС сервера под управлением FreeBSD и Apache не требовали остановки во время обновления ПО, Windows должна справится с этой задачей.
Обновления ПО на Hotmail бывают двух видов: обновления контента и обновления кода. Обновления контента затрагивают только файлы с данными, которые, в основном, определяют, что пользователь видит на экране и могут быть затребованы по собственному расписанию. Apache позволяет производить обновления кода и контента без остановки сервиса. Обновления могут быть развернуты непосредственно, когда данные уже обновлены локально. Обновления так же можно спланировать по времени - в заданный момент, подготовленные на серверах обновления будут запущены в работу. Обновления по времени используются, когда при обновлении не должна нарушаться целостность приложения на всем узле, этого иногда сложно добиться, производя обновление на нескольких тысячах серверов по одной сети.

Техника обновления ПО.

Назад к содержанию

Apache, работающий под Unix легко работал с обоими типами обновлений. CGI приложение может быть заменено даже если старая версия кода еще исполняется, при следующим обращении к этому приложению уже будет использован обновленный код. То же относится и к контенту. Если возникала необходимость обновить конфигурацию Apache, использовалась процедура, сигнализирующая Apache о необходимости перезапуска и обновления конфигурации, это занимало около секунды.
К сожалению, IIS 5.0 не поддерживает корректно ни один из способов обновления. Когда IIS непосредственно взаимодействует с контентом, он блокирует его. К счастью, это не относится к большей части обновлений на Hotmail. Наибольшей проблемой является обновление фильтров ISAPI, которое должно происходить при остановленном сервисе IIS. Весь процесс может занять более минуты.
Персоналом Hotmail была разработана технология, которая использовала тонкий фильтр ISAPI ("клин"). Приложения запускались в виде отдельных DLL и пропускались через все запросы ISAPI. Кроме того, в определенном месте производился контроль за обновлениями, и когда поступал сигнал о необходимости обновления DLL, посылался сигнал, завершающий все старые запросы до обновления DLL. Эта технология была доступна и для команды IIS.

Intellimirror.

Назад к содержанию

Было решено не использовать обновления на базе Intellimirror. Во-первых, Intellimirror требовало использования AD. Во-вторых, Intellimirror (работая совместно с Installer'ом) могло производить обновления ПО только в момент подключения пользователя или в момент перезагрузки. Поскольку подключения пользователей происходят в случайные моменты времени и требовалось избегать перезагрузок, Intellimirror не вписывалось в общую концепцию узла.

Формат и механизм распространения ПО.

Назад к содержанию

В Unix новый код распространялся в виде tar-файлов, установка которых производилась утилитой rdist.
Разработчики рассмотрели возможность использования технологии MS Installer для формирования пакетов обновлений. Хотя этом метод соответствовал всем требованиям (включая распаковку файлов требуемых версий в необходимое место, создания изменений в реестре и исполнение произвольного кода во время инсталляции), он предполагал очень сложное освоение, в противоположность нескольким подобным пакетам ПО. Было решено использовать zip-файлы для распространения обновлений.
Механизм rdist хорошо приспособлен для инсталляций и обновлений на большом количестве идентичных машинах. С центрального узла администратор может создать список серверов и отправить пакет обновлений к ним. Демон (сервис) rdist, работающий на удаленном сервере, извлечет файлы из архива в требуемое место и выполнит требуемые операции до и после процесса инсталляции. Это, в целом, соответствует возможностям MS Installer, дополняя их возможностью работы со списком серверов. Разработчики Hotmail остановились на Windows версии демона rdist.

Мониторинг и ведение журналов.

Назад к содержанию

Центр сетевых операций.

Назад к содержанию

Мониторинг инфраструктуры Hotmail производится удаленно, в центре управления, расположенном вместе с командой разработчиков на территории университета Саннивал (Sunnyvale). Здесь находится много инструментов для слежения за производительностью всего узла. Некоторые из них производят измерения внешних характеристик системы и не требуют модификации. Остальные используют информацию, передаваемую непосредственно серверами (счетчики производительности, статистика о дисковом пространстве и т.п.). Оказалось несложно написать скрипты, которые собирали необходимую информацию о производительности Windows и отсылали ее на консоли управления.

Автономный мониторинг.

Назад к содержанию

Некоторые способы самодиагностики и мониторинга серверов осуществляются при помощи определенных операций (обычно - скриптов), выполняемых через определенные промежутки времени. Эти временные интервалы могут колебаться от минуты до недели.
При использовании FreeBSD, подобные задачи управлялись сервисом cron. Все задачи перечислялись в файле, каждая строка которого описывала конкретную задачу. Редактирование файла легко производить из командной строки (или с помощью утилиты rdist), перезапись содержимого файла - гарантированный способ получения требуемого списка задач. Задачи могут быть запланированы для однократного или периодического исполнения с интервалом до одной минуты.
Хотя Windows сервис Task Scheduler в целом способен управлять такими задачами, его интерфейс не позволяет управлять всем процессом.

• GUI интерфейс, который используется для установки исполняемых задач, является очень ресурсоемким и подверженным ошибкам.
• Команда at не позволяет обслуживать задачи чаще одного раза в сутки.
• Команда jt предложенная разработчиками Task Scheduler, является неудобной для использования (запланировано ее тестирование).
• Ни один из рассмотренных трех интерфейсов на позволяет замещать текущий список задач.

Было решено использовать сервис cron. Как описано выше, использование сервисов Unix (или любых других пакетов, увеличивающих цену ПО), является плохой моделью для других проектов. Перед разработчиками была поставлена задача улучшить интерфейс командной строки Task Scheduler в Whistler.

Ведение журналов.

Назад к содержанию

Есть один недостаток в ведении журналов (syslog) в Unix. Ядро, стандартные сервисы и приложения могут записывать строки текста в системный журнал, который по сути является одним текстовым файлом. Т.о. важное сообщение может отобразиться на консоли и может быть отправлено по e-mail, пока его информационная часть записывается в журнал. Администратор может изменить способ получения и фиксирования сообщений не производя перекомпилирование кода.
ПО, подобное используемому на Hotmail, часто использует доступ к syslog для записи различной статистической информации (например, создание учетной записи или отправка сообщения по e-mail). Администраторы могут использовать другие инструменты для анализа журналов, их архивирования или простого подсчета инцидентов. Обычно, события поступали в журнал каждую секунду; высокая производительность для работы с журналом ядра не требовалась.
В Windows 2000 нет такого же сочетания удобства и конфигурируемости системного журнала, хотя журнал событий (event log) близок к этому. Для удобства и, в то же время, избежания изменения кода, решено использовать свойства syslog подсистемы Interix, учитывая потенциальные проблемы повышения общей стоимости проекта, оговоренное выше.
В Whistler представлен Enterprise Event Log, упрощенная версия WMI, который должен обеспечить необходимую функциональность. При ближайшем рассмотрении, журнал работы ядра так же соответствует всем требованиям. Любое изменение должно вызывать лишь минимальные изменения кода ПО (возможно использование макросов), желательно не затрагивать вызовы syslog, для уменьшения количества переписываемого кода.

Специальное обслуживание.

Назад к содержанию

Иногда после развертывания системы у администраторов возникает необходимость внести изменения в конфигурации серверов всего узла. Rdist позволяет изменять конфигурацию, если изменения конфигурации незначительны, используется rsh. Ключевой особенность Unix и в этом случае является возможность производить подобные манипуляции исключительно из командной строки.
Windows должна предоставить подобную функциональность при работе как с отдельными группами серверов, так и со всеми серверами. Отдельные команды, конвейеры или скрипты (командные скрипты или COM-скрипты) будут решать эти задачи, но скрипты необходимо сначала загрузить на сервер, а затем там исполнить (и, по необходимости, удалить). Скрипты должны уметь отложить свой запуск до определенного момента, вероятно, заданного усовершенствованным Task Scheduler'ом. Другими словами, Windows должна поддерживать пакетную обработку старого образца.
Специфическим примером, когда невозможно применить пакетную обработку, является настройка сетевых плат; например, требуется изменить скорость работы сетевых адаптеров с 10 до 100Mbps (в определенное время) или изменить установки MTU. Конфигурация адаптеров Ethernet различается у разных производителей, стандартный GUI использует конфигурацию, расположенную в реестре. GUI, в целом, не приспособлен для пакетной обработки. Существует возможность производить изменения непосредственно в реестре, но это может потребовать нежелательной перезагрузки. Время неработоспособности сети, вызванное перезапуском сетевого адаптера - это максимальный допустимый простой.
Командой Hotmail, совместно с сетевыми инженерами, разработано простое приложение, которое записывало необходимые данные в реестр и перезапускало сетевую плату для загрузки новой конфигурации (используя недокументированные функции). Было рекомендовано внести такие возможности в стандартную ОС.

Работа с администраторами Unix.

Назад к содержанию

Помощь администраторам системы UNIX с переходом к Windows - опыт сам по себе, и это необходимо изучить тщательнее. Опять же, все данные были получены от единственного крупного проекта, но он является достаточно типичным. Далее представлен обзор человеческих факторов в проекте.
В начале, план перехода с FreeBSD на Windows вызвал широкую реакцию - от скептицизма до полного неприятия, подобная реакция ожидалась со стороны тех, кто пытался использовать сильные стороны Unix в программных продуктах Microsoft.
Был проведен опрос обслуживающего персонала по поводу их ежедневных задач по работе с ОС и ПО. Вместо набора задач были получены наборы Unix команд, которые применялись для решения задач. Хотя были получены не совсем ожидаемые результаты, это дало хороший повод непосредственно проверить все особенности и узнать, будет ли Windows точным эквивалентом на уровне системы или потребуется применение Resource Kit или скриптов. Нашлось только несколько не удовлетворяющих общей концепции моментов. По существу, это была одноразовая работа, поскольку, возможные проблемы легко решались средствами Windows, но она явилась хорошей возможностью повысить доверие среди обслуживающего персонала.
Логично, что некоторые люди из мира Unix не делали различий для ОС семейства Windows, они полагали, что Windows 2000 унаследовала все ошибки и недоработки Windows 95. Те люди, кто был хорошо знаком с Windows NT, слабо владели не-GUI операциями (откровенно говоря, и авторы оригинального документа - тоже); набор команд Windows и Resource Kit достаточно широк, как уже говорилось, они содержат множество недостатков и неточностей и синтаксисе.
Персонал, не занятый текущим обслуживанием системы осуществлял преобразование узла. Когда развертывание новой системы подходило к концу, началось обучение обслуживающего персонала работе с новыми инструментами и принципами. Жизнь взяла свое - наибольший интерес у персонала вызывали, все-таки, запуск и администрирование системы, как только они нашли требуемые для работы инструменты, стандартные или самостоятельно созданные, работа вошла в привычное русло. Некоторые однодневные курсы были прочтены персоналу для подготовки к управлению отладкой системы, работы с заплатками (hotfix) и т.п. К этому времени, персонал убедился, что Windows - это настоящая и неожиданно сильная ОС.

Подведя итог:

• Совершенно ясно, что Windows 2000 является современной ОС, это не Windows 9х.
• Скептики убедились, что современные ОС имеют мало фундаментальных отличий, это было продемонстрировано на примере основанных на командной строке инструментов для мониторинга активной системы.
• Высоко профессиональные сотрудники всегда способны расширять свою область действия.

Выводы.

Назад к содержанию

Далее приведены основные выводы, сделанные по ходу проекта.

1. Требуется точный, всесторонний и вдумчивый подход к смешанному управлению группой серверов. Это не означает, что необходимо слепо держаться модели Unix для работы со списком машин с помощью команды rsh или обновления конфигурации на серии машин. Главная задача - это возможность управления компьютерами как множеством, выполнение этой задачи с помощью GUI не обязательно является недостатком, пока задача успешно решается. Это применимо как к настройке системы, так и к распространению ПО.
2. Использование NLBS экономически невыгодно, поскольку она требует Advanced Server, и персоналом Hotmail было найдено удачное решение, не использующее NLBS и ее особенности.
3. Метабаза должна быть заменена чем-то более удобным для администрирования и понимания, а так же содержать меньше скрытых подвохов. Разработчики IIS6 уже ознакомлены с этим мнением.
4. Должна существовать возможность настроить и блокировать одну систему, и распространить изменения в заданном классе систем.
5. Windows слишком сложна для освоения, особенно в первое время отказа от Unix. В ней присутствуют слишком много вещей, которые необходимо учитывать при планировании установки. Обычно на это нет времени. Проблема в том, что IT-образование основывается на Unix и его использовании. Необходимо тщательно поддерживать баланс между сложностью и инвариантностью.
6. Основное, что требуется во время перевода Интернет сайта с Unix на Windows - это возможность быстро заменить существующее ПО и методы управления чем-то, как минимум, эквивалентным по качеству. Улучшения, произошедшие автоматически - это хорошо, но применение новых технологий и методов программирования необходимо отложить до тех пор, пока они задерживают главную цель - поддерживать бесперебойную и конкурентоспособную работу узла. Все остальное - это плата за чистую прибыль.

[2]
В Whistler станет доступным вход терминального пользователя с консоли, но как будет показано позже, Terminal Server не является идеальным решением. Назад.

[3]
Например, требуется уменьшить значение одного из параметров интерфейса TCP/IP - MTU. Нет команды, позволяющей выполнить такую операцию, но легко найти код в стеке сетевых протоколов, изменить его и пересобрать ядро. Назад.

[4]
Одно исключение: вызов библиотеки Windows на исполнение, используя строку с произвольным регистром, может привести к неожиданным проблемам, вероятно потому, что у простых Unix систем отсутствует локализация. Назад.