РАЗВЕРТЫВАНИЕ РЕШЕНИЙ В ФЕРМЕ СЕРВЕРОВ

Предшествующий уровень техники

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

В отношении этих и других коммерческих действий организации и другие поставщики содержимого (контента) используют серверы для того, чтобы обрабатывать запросы от различных пользователей. Различные архитектуры используются при обработке этих запросов; зачастую распределенные архитектуры, в которых набор серверов в кластере ("ферма серверов") используется для того, чтобы обрабатывать запросы. В этой архитектуре на основе ферм серверов набор серверов виден пользователю как один сервер. Может быть использован механизм балансировки нагрузки для того, чтобы определять то, какой сервер в ферме серверов должен быть использован для того, чтобы обрабатывать различные запросы, направляемые в ферму серверов.

Конфигурирование и обслуживание различных серверов в ферме серверов исторически было сложной задачей. Эта задача еще более усложнялась по мере того, как число серверов, используемых в заданной ферме серверов, возрастало. Чтобы надлежащим образом обслуживать серверы в ферме серверов, серверы периодически должны обновляться. Эти обновления включают в себя конфигурирование данных и служб, предоставляемых сервером, чтобы обеспечить, что настройки и службы в каждом из серверов согласованы друг с другом, и поддерживать практически в реальном времени сведения о различных службах и приложениях, которые имеются на серверах фермы серверов.

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

Такое отдельное развертывание пользовательских решений приводит к нескольким проблемам. Во-первых, если несколько серверов используются для того, чтобы поддерживать одно и то же логическое содержимое, развертывание пользовательских решений отдельно на каждом сервере может приводить к несогласованному развертыванию. Несогласованное развертывание решений на серверах может приводить к нежелательному функционированию одного и того же логического содержимого. Во-вторых, администратор может делать ошибки в ходе развертывания нескольких решений отдельно на каждом сервере. Как результат, ошибки проявляют себя на серверах как несогласованные и трудные в диагностировании проблемы. Администратору трудно обеспечить то, чтобы несколько серверов были согласованы друг с другом в отношении состояния развернутых решений. Следовательно, желательно централизованно сохранять все конфигурационные данные, такие как настройки приложений и решения, для каждого сервера в ферме серверов. Также желательно, чтобы все централизованно сохраненные конфигурационные данные могли быть автоматически развернуты согласованным образом на всех серверах в ферме серверов по запросу.

Сущность изобретения

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

Другой аспект изобретения предоставляет несколько механизмов предоставления решений в хранилище решений. Такой механизм может заключаться в том, чтобы использовать утилиту командной строки или Web-интерфейс, чтобы предоставлять решения в хранилище решений. Web-интерфейс может быть запущен в системе, удаленной по отношению к ферме серверов. Предпочтительно, каждое предоставленное решение расширяет объектную модель конфигурации, что позволяет добавить решение в хранилище решений без необходимости понимания или модификации схемы конфигурационной базы данных разработчиком решения. Предоставление решения может требовать специальных прав доступа к хранилищу решений. Предоставленное решение также, возможно, должно проходить определенные проверки правильности данных, чтобы гарантировать то, что решение является логически корректным, свободным от вирусов или иным образом совместимым со средой фермы серверов. Любое решение, не прошедшее проверку правильности данных, не развертывается в ферме серверов.

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

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

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

Данное изложение сущности предусмотрено для того, чтобы в упрощенной форме представить выбор идей, которые дополнительно описываются ниже в подробном описании. Это раскрытие сущности не предназначено для того, чтобы идентифицировать ключевые признаки или важнейшие признаки заявляемого предмета изобретения, а также не предназначено для того, чтобы быть использованной в качестве помощи при определении объема заявляемого изобретения.

Перечень фигур чертежей

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

Фиг.1 - блок-схема, иллюстрирующая примерную сеть систем обработки данных, в которой могут быть реализованы аспекты изобретения;

Фиг.2 - блок-схема, иллюстрирующая примерную ферму серверов, подходящую для использования на фиг. 1;

Фиг.3 - блок-схема, иллюстрирующая примерную ферму серверов, в которой решения предоставляются в централизованное место хранения в ферме серверов;

Фиг.4 - блок-схема, иллюстрирующая примерную ферму серверов, в которой решения развертываются на каждом сервере из ферм серверов; и

Фиг.5A-5B - логические блок-схемы, иллюстрирующие примерный процесс развертывания решений в ферме серверов.

Подробное описание примерных вариантов осуществления

Фиг.1 иллюстрирует графическое представление сети 100 систем обработки данных, в которой может быть реализован примерный вариант осуществления изобретения. Сеть 100 систем обработки данных включает в себя сеть 102, которая является средой для того, чтобы предоставлять линии связи между различными устройствами и вычислительными машинами (компьютерами), соединенными вместе в рамках сети 100 систем обработки данных. Сеть 102 может включать в себя соединения, такие как линия проводной или беспроводной связи, оптоволоконные кабели и т.п.

Как показано на фиг.1, сеть 100 систем обработки данных включает в себя, по меньшей мере, одну ферму 104 серверов и один или более клиентов 108-112, все из которых соединены с сетью 102. Ферма 104 серверов, в общем, состоит из набора серверов, который представляется как один сервер или "виртуальный" сервер для обработки запросов. Клиенты 108, 110 и 112 - это клиенты для фермы 104 серверов. Этими клиентами 108, 110 и 112, например, могут быть персональные вычислительные машины или сетевые вычислительные машины. В общем, ферма 104 серверов предоставляет данные, такие как загрузочные файлы, образы операционной системы, приложения, Web-содержимое, клиентам 108-112. Сеть 100 систем обработки данных может включать в себя дополнительные серверы, клиенты и другие непоказанные устройства.

В проиллюстрированном примере сетью 100 систем обработки данных является Интернет, при этом сеть 102 представляет набор сетей и шлюзов по всему миру, которые используют стек протоколов TCP/IP для того, чтобы обмениваться данными друг с другом. Сердцем Интернета является магистраль высокоскоростных линий передачи данных между главными узлами или узловыми вычислительными машинами. Эти узлы или узловые вычислительные машины включают в себя тысячи коммерческих, правительственных, образовательных и других вычислительных систем, которые маршрутизируют данные и сообщения. Сеть 100 систем обработки данных также может быть реализована как ряд различных типов сетей, таких как, к примеру, сеть интранет, локальная сеть (LAN) или глобальная сеть (WAN). Фиг. 1 предоставляется в качестве примера, а не в качестве архитектурного ограничения изобретения.

Фиг.2 - это блок-схема фермы 104 серверов в соответствии с примерным вариантом осуществления изобретения. Как показано на фиг.2, ферма 104 серверов включает в себя множество серверов, например серверы 202A, 202B, 202C, каждый из которых обменивается данными с другими посредством системы 212 связи. Система 212 связи используется для того, чтобы обрабатывать запросы и ответы по маршрутизации, направляемые в ферму 104 серверов. Система 212 связи может принимать различные формы, в том числе, к примеру, шины, сети, совместно используемого запоминающего устройства и т.п.

Ферма 104 серверов может включать в себя менеджер (средство управления) 214 загрузки, который соединен с системой 212 связи и который служит для того, чтобы принимать запросы, направляемые в ферму 104 серверов из сети 102. Запросы могут включать в себя запросы, принимаемые от клиентов 108-112 (фиг.1), и могут включать в себя, например, запросы на Web-страницы, файлы или другое содержимое. Менеджер 214 загрузки имеет такую функциональность, чтобы распространять запросы на серверы 202A-202C для обработки. По сути, менеджер 214 загрузки имеет такую функциональность, чтобы обеспечивать то, что ни один из серверов 202A-202C фермы 104 серверов не перегружается излишне запросами, выполняемыми фермой 104 серверов.

В вариантах осуществления изобретения ферма 104 серверов включает в себя конфигурационную базу 218 данных, которая сохраняет все конфигурационные данные для фермы 104 серверов. В вариантах осуществления изобретения конфигурационная база 218 данных - это главная копия всех конфигурационных данных в ферме 104 серверов, которая дает возможность одной и той же информации быть доступной в рамках набора серверов в ферме 104 серверов. Конфигурационная база 218 данных функционально соединена с системой 212 связи, чтобы предоставить возможность отправки конфигурационных данных в каждый из серверов 202A-202C фермы 104 серверов. Конфигурационная база 218 данных используется для того, чтобы управлять настройками конфигурации каждого из серверов 202A-202C. Следовательно, конфигурационная база 218 данных выступает в качестве центрального репозитория для всех конфигурационных настроек, которые должны быть изменены и/или добавлены в различные серверы 202A-202C фермы 104 серверов. Предоставление конфигурационной базы 218 данных устраняет необходимость обновления и/или добавления конфигурационных настроек серверов 202A-202C вручную. Помимо хранения информации о топологии серверов, конфигурационная база 218 данных также может хранить конкретные для приложения настройки, такие как политики безопасности, антивирусные определения, языковые настройки и т.д. В вариантах осуществления изобретения конфигурационные данные могут сохранять одно или более решений, которые применимы к серверам в ферме 104 серверов. Решение включает в себя пакетные файлы, которые содержат код приложений, определения и локализованные ресурсы, которые могут инструктировать сервер по предоставлению конкретного содержимого или служб. Предпочтительно, как показано на фиг. 3, конфигурационная база 218 данных может включать в себя отдельный блок, называемый хранилищем 300 решений. Хранилище 300 решений включает в себя набор логических объектов. Каждый логический объект включает в себя двоичные файлы, которые представляют решение, а также информацию о режиме, касающуюся состояния каждого решения, например выбрано или нет решение для развертывания или развернуто или нет решение, и т.д.

Ферма 104 серверов также может включать в себя, по меньшей мере, одно хранилище 220 содержимого. Аналогично другим функциональным аспектам фермы 104 серверов хранилище 220 содержимого функционально соединено с системой 212 связи, чтобы предоставлять возможность распространять информацию, сохраненную в хранилище 220 содержимого, в различные компоненты фермы 104 серверов. В примерных вариантах осуществления изобретения хранилище 220 содержимого содержит данные для серверов в ферме 104 серверов. Эти данные включают в себя документы, элементы данных, обсуждения, задачи и т.д. Хранилище 220 содержимого работает вместе с конфигурационной базой 218 данных, чтобы предоставлять содержимое, конкретно связанное с данным конфигурационным изменением одного или более из серверов 202A-202C. В примерных вариантах осуществления изобретения хранилище 220 содержимого не взаимодействует с конфигурационной базой 218 данных. Конфигурационная база 218 данных содержит таблицу соответствия, по какому содержимому сервера база данных хранит данные. Как результат, необязательно опрашивать каждое хранилище 220 содержимого в ферме 104 серверов, чтобы проверять то, содержит ли хранилище содержимого содержимое для конкретного сервера в ферме 104 серверов.

В примерных вариантах осуществления изобретения ферма 104 серверов является произвольно наращиваемой. Это включает в себя то, что ферма 104 серверов может быть произвольно дополнена несколькими серверами, отличными от серверов 202A-202C. Помимо этого, ферма 104 серверов может включать в себя несколько хранилищ 220 содержимого, чтобы сохранять данные для нескольких серверов в ферме 104 серверов.

В частности, примерные варианты осуществления изобретения позволяют решениям быть добавляемыми в конфигурационную базу 218 данных и/или хранилище 300 решений посредством нескольких транспортных механизмов. Фиг.3 иллюстрирует примерные транспортные механизмы, посредством которых решения могут предоставляться и добавляться в конфигурационную базу 218 данных. Одним примерным транспортным механизмом является интерфейс 301 командной строки. Другим примерным транспортным механизмом является Web-интерфейс 304. Web-интерфейс 304 может быть вне фермы серверов и обменивается данными с конфигурационной базой 218 данных посредством сети 102. Этот Web-интерфейс 304 предоставляет удаленные возможности работы для предоставления решений. Другие альтернативные транспортные механизмы для интегрирования решений в конфигурационную базу 218 данных включают в себя использование удаленных вызовов процедур или SOAP-интерфейс для того, чтобы упрощать автоматическое предоставление и развертывание решений для фермы 104 серверов.

В примерных вариантах осуществления изобретения предоставляемые решения расширяют объектную модель 302 конфигурации, которая обеспечивает произвольное расширение конфигурационной базы 218 данных. Объектная модель 302 конфигурации позволяет пользователю наращивать или обновлять конфигурационные данные для фермы 104 серверов без необходимости для пользователя понимать или модифицировать схему конфигурационной базы 218 данных. В примерном варианте осуществления изобретения объектная модель 302 конфигурации включает в себя класс на базе Net-объектов. Пользователь может расширять базовый класс посредством формирования подклассов или создания экземпляра базового класса с конкретными конфигурационными данными. Эти данные затем интегрируются в конфигурационную базу 218 данных. Как результат, пользователю требуется только внимательно проанализировать объектную модель 302 конфигурации, чтобы добавлять различные типы данных в конфигурационную базу 218 данных. Пользователю не нужно понимать или модифицировать схему конфигурационной базы 218 данных. В примерном варианте осуществления изобретения объекты, содержащие конфигурационную информацию для приложения, либо извлекаются из, либо содержатся в базовом классе с названием, к примеру, PersistedObject. Когда обновляется, этот класс упорядочивает в XML все поля, помеченные атрибутом "persisted", и записывает XML-блоб в конфигурационную базу 218 данных. Базовый класс содержит код для того, чтобы упорядочивать все свои члены, которые являются базовыми типами, другими объектами PersistedObject или наборами одного из двух элементов. Эта конструкция позволяет новым объектам, содержащим конфигурационные данные для фермы 104 серверов, быть добавляемыми в конфигурационную базу 218 данных по мере необходимости.

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

Конфигурационная база 218 данных и/или хранилище 300 решений таким образом предоставляют централизованное место хранения для хранения решений, предоставляемых разработчиками и/или администраторами фермы 104 серверов. Предоставление решений в конфигурационную базу 218 данных может быть независимо защищено от возможности развертывать решения из конфигурационной базы 218 данных. Эта сегрегация позволяет администраторам фермы 104 серверов давать возможность разработчикам предоставлять решения, при этом оставляя возможность независимо контролировать эти предоставления до их развертывания.

Варианты осуществления изобретения автоматически развертывают заданное решение на нескольких серверах в ферме серверов, такой как ферма 104 серверов. Варианты осуществления изобретения предоставляют основанный на извлечении механизм запрашивания и извлечения решений из конфигурационной базы 218 данных в сервер фермы 104 серверов. В примерных вариантах осуществления изобретения этот основанный на извлечении механизм реализуется посредством службы синхронизации, содержащейся в каждом сервере фермы 104 серверов. Служба синхронизации запрашивает конфигурационную базу 218 данных, чтобы синхронизировать все ожидающие изменения. Эти ожидающие изменения включают в себя все изменения в хранилище 300 решений или наборе заданий синхронизации, которые выполняются по всей ферме 104 серверов. Применение такого механизма на основе извлечения устраняет необходимость открывать дополнительный TCP/IP-порт на сервере, таком как сервер 202A, чтобы обмениваться данными с конфигурационной базой 218 данных. За счет отсутствия необходимости дополнительного открытого порта меньший риск возникает на сервере вследствие неоткрывания потенциального входа для хакеров, вирусов и других форм атак. Фиг.4 иллюстрирует примерную реализацию механизма на основе извлечения для запрашивания и извлечения решений из конфигурационной базы 218 данных. Как показано на фиг.4, сервер 202A содержит службу 402 синхронизации. Функционально, служба 402 синхронизации опрашивает конфигурационную базу 218 данных и/или хранилище 300 решений, чтобы определять то, какие решения должны быть (или есть) развернуты в ферме 104 серверов и, следовательно, на сервере 202A.

В вариантах осуществления изобретения администратор фермы 104 серверов может анализировать список предоставленных решений в хранилище 300 решений. Администратор может выбирать то, чтобы развертывать одно или более из предоставленных решений, и может выбирать делать это для набора серверов в ферме 104 серверов или от имени всей фермы 104 серверов.

В вариантах осуществления изобретения администратор также может выбрать развертывать решение сразу при необходимости ("немедленное развертывание") или позднее ("отложенное развертывание"). Когда имеется только один сервер в ферме 104 серверов либо когда отложенное развертывание решений в хранилище 300 решений необязательно, развертывание решений в хранилище 300 решений выполняется немедленно. Предусмотрено два типа немедленного развертывания. В случае односерверной фермы серверов немедленное развертывание осуществляется на той же системе, где администратор выдает запрос на развертывание. Основанного на извлечении механизма, такого как служба 402 синхронизации, не требуется. В многосерверной ферме 104 серверов немедленное развертывание использует службу 402 серверов сначала как механизм связи, чтобы сообщать службам синхронизации других серверов в ферме 104 серверов начинать развертывание. Когда администратор хочет отложить развертывание решений в многосерверной ферме 104 серверов, к примеру, до полуночи, когда использование фермы 104 серверов низкое, развертывание решения называется отложенным развертыванием. Служба 402 синхронизации используется в отложенном развертывании.

В примерных вариантах осуществления изобретения служба 402 синхронизации выполняет развертывание решений в двух фазах. На первой фазе служба 402 синхронизации предписывает серверу 202A извлечь пакет решений из конфигурационной базы 218 данных, распаковать пакет решений и сохранить файлы решений в заданных каталогах на сервере 202A. После того как все серверы в ферме 104 серверов развернули решение единообразно и не было сбоев, служба 402 синхронизации инициирует вторую фазу. В ходе второй фазы служба 402 синхронизации устанавливает файлы решений, исполняет все коды пользовательских решений для сервера 202A и обновляет конфигурационную информацию в конфигурационной базе 218 данных. Конфигурационная информация в конфигурационной базе 218 данных не затрагивается, если в одном или более серверов в ферме 104 серверов не удается развернуть решение надлежащим образом.

В примерных вариантах осуществления изобретения служба 402 синхронизации использует ограниченную привилегию для того, чтобы развертывать решение. Эта ограниченная привилегия позволяет службе 402 синхронизации обмениваться данными и обновлять конфигурационную базу 218 данных, но не обрабатывать объектные сущности на сервере 202A, где запущена служба 402 синхронизации. Данная сегментация обеспечивает то, что служба 402 синхронизации не принимает больше привилегий безопасности, чем требуется. Тем не менее, для таких операций, как установка файлов решений в привилегированные области на сервере, ограниченных привилегий службы 402 синхронизации недостаточно. В данном случае служба 402 синхронизации обменивается данными со второй службой, называемой службой 404 администрирования. Служба 404 администрирования имеет повышенные полномочия на сервере 202A и может устанавливать файлы решений в привилегированные сервера 202A.

Некоторые варианты осуществления изобретения также предоставляют механизм синхронизации, который позволяет администратору извлекать обновленные решения из конфигурационной базы 218 данных и применять решения к конкретному серверу в ферме 104 серверов, например серверу 202A. Этот механизм позволяет администратору восстанавливать конкретный сервер в ферме 104 серверов или подготавливать новый сервер, который только что присоединился к ферме 104 серверов, чтобы поддерживать сервер синхронизированным с настройками на других серверах в ферме 104 серверов. Механизм синхронизации сравнивает набор развернутых решений в хранилище 300 решений с набором файлов и изменений, которые локально развернуты на конкретном сервере, и загружает из хранилища 300 серверов файлы или изменения, которые отсутствуют. Механизм синхронизации может быть использован для того, чтобы восстанавливать состояние сервера посредством его согласования с состоянием в хранилище 300 решений, указанным для всех серверов в ферме 104 серверов. Механизм синхронизации также может позволять администратору явно выбирать то, чтобы обновлять один или более серверов, а не использовать службу 402 синхронизации для того, чтобы развертывать решения на все серверы в ферме 104 серверов.

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

Фиг.5A-5B включают в себя блок-схему, иллюстрирующую примерный процесс 500 развертывания решения на серверах в ферме серверов. В некоторых вариантах осуществления изобретения, после того как решение предоставлено в конфигурационную базу данных фермы серверов, решение проходит проверку. Проверка решения включает в себя определение того, является ли решение логически корректным, свободным от вирусов или иным образом совместимым с окружением фермы серверов. Таким образом, процесс 500 начинается посредством проверки всех предоставленных решений. См. этап 502. Далее процесс 500 продолжается, чтобы определить то, является ли проверка успешной. См. этап 504 принятия решения. Если проверка выполнена с ошибкой, процесс 500 переходит к пункту A продолжения. Если ответ на этапе 504 принятия решения "ДА", то это означает, что проверка успешная, решение готово к развертыванию. Альтернативно, предоставленное решение проходит процесс проверки до того, как решение должно быть развернуто в ферме серверов.

Как упомянуто выше, развертывание решений может выполняться сразу после выбора администратором решения для развертывания. Развертывание решений также может назначаться на более позднее время, например на полночь, когда использование фермы серверов низкое. Процесс 500 позволяет пользователю, например администратору, планировать развертывание решений. См. этап 506. Решение развертывается на всех серверах в ферме серверов. Таким образом, процесс 500 проходит цикл, который начинается с этапа 508 принятия решения и завершается этапом 518 принятия решения, чтобы развернуть решение на каждом сервере в ферме серверов. В ходе цикла процесс 500 сначала определяет, принял ли сервер вызов от службы синхронизации, запущенной на сервере, такой как служба 402 синхронизации, проиллюстрированная на фиг.4. См. этап 508 принятия решения. Если ответ "НЕТ", процесс 500 далее не продолжается. Если ответ на этапе 508 принятия решения "ДА", что означает, что сервер принял вызов от службы синхронизации, чтобы развернуть решение, процесс 500 продолжается, чтобы дать возможность серверу извлечь решение из конфигурационной базы данных, которая централизованно хранит решения для фермы серверов. См. этап 510. Затем сервер разворачивает файлы, содержащиеся в развертываемом решении, в соответствующих каталогах на сервере. См. этап 512. При необходимости процесс 500 позволяет службе администрирования на сервере, такой как служба 404 администрирования, проиллюстрированная на фиг.4, выполнять процесс установки решения. См. этап 514. Процесс установки копирует файлы решения в соответствующие каталоги и устанавливает надлежащие конфигурации решения. После завершения процесса установки служба синхронизации отправляет сообщение в конфигурационную базу данных, указывающее то, что решение развернуто и установлено на сервере. См. этап 516. Далее процесс 500 проверяет то, требуется ли еще одному серверу в ферме серверов развернуть решение. См. этап 518 принятия решения. Если ответ "ДА", процесс 500 возвращается к этапу 508 принятия решения, чтобы проверить то, может ли он начать развертывать решение на другом сервере. Если ответ на этапе 518 принятия решения "НЕТ", означая, что более нет серверов в ферме серверов, требующих развернуть решение, процесс 500 переходит к границе B продолжения.

В вариантах осуществления изобретения решение развертывается на всех серверах в ферме серверов, только если решение проходит проверку. Следовательно, из границы A продолжения (фиг.5B), когда решение не проходит проверку, сообщение отправляется пользователю, к примеру администратору, который запросил развернуть решение в ферме серверов, чтобы указать то, что проверка решения завершилась с ошибкой. См. этап 520. Как результат, все файлы решений, существующие на серверах в ферме серверов, удаляются, хотя конфигурационная база данных предпочтительно по-прежнему хранит пакет решений. См. этап 522. Затем процесс 500 завершается и решение не развертывается ни на одном из серверов в ферме серверов.

Наоборот, когда решение успешно развернуто и установлено на всех серверах фермы серверов, серверы исполняют любой код пользовательских решений и конфигурационная база данных обновляет свои данные, касающиеся решения. Например, состояние решения в конфигурационной базе данных может быть изменено с "должно быть развернуто" на "развернуто". Следовательно, из границы B продолжения (фиг.5B), после того как серверы в ферме серверов успешно установили решение, процесс 500 продолжается, чтобы обновить конфигурационную базу данных сведениями о решении. См. этап 524. Далее процесс 500 продолжается, чтобы дать возможность всем серверам в ферме серверов исполнять любой код пользовательских решений, ассоциативно связанный с этими решениями. После этого процесс 500 завершается.

Хотя проиллюстрированы примерные варианты осуществления настоящего изобретения, следует принимать во внимание, что различные изменения могут выполняться в них без отступления от существа и объема настоящего изобретения.