Тезисы

Аннотация

Как известно, существуют два основных подхода к масштабированию приложений: вертикальное масштабирование, когда хостом выступает отдельная машина, вычислительные мощности которой наращиваются по мере необходимости, и горизонтальное масштабирование, когда вычислительная система состоит из группы однотипных серверов потребительского класса, работающих совместно. Повышение масштабируемости в этом случае осуществляется простым добавлением новых узлов в группу. Каждый подход имеет свои сильные и слабые стороны. В настоящем докладе разбираются условия, при которых предпочтительным вариантом является горизонтальное масштабирование в целом, и, в частности, метод, известный как зависимая от данных маршрутизация (Data Dependent Routing) при построени горизонтально масштабируемых систем. Доклад основывается на материалах лаборатории масштабирования SQL Server (SQL Server Scalability lab), занимавшейся практическим сценарием построения коммуникационной платформы для сайта MSN (The Microsoft Network). В качестве операционной системы выступала Microsoft Windows® Server™ 2003, Enterprise Edition.

Введение

Предыдущее десятилетие ознаменовалось взрывным ростом объемов данных. Сейчас, когда многие бизнес-приложения изначально ориентированы на работу в Интернете, компании взаимодействуют с миллионами он-лайновых пользователей, которые делают покупки, хранят сообщения электронной почты, просматривают финансовую информацию и т.д. Сердцем корпоративных информационных систем выступают, естественно, базы данных. SQL Server является одной из лидирующих платформ СУБД в центрах данных.

Каждое соединение и каждый запрос потребляют процессорное время, память, дисковые, сетевые и др.ресурсы. Поэтому традиционно масштабируемость достигалась путем апгрейда стандартных SMP-архитектур, когда в сервер ставились дополнительные процессоры, память, диски, сетевые карты и другое необходимое аппаратное обеспечение. Вертикальное масштабирование является достаточным в большинстве нынешних сценариев внедрения SQL Server. Однако машину нельзя апгрейдить до бесконечности. Когда мы ежесекундно имеем дело с миллионами пользовательских запросов могут происходить ситуации, когда сервер просто достигает предела своих аппаратных характеристик. В этом случае решение видится в горизонтальном масштабировании, когда данные и нагрузка распределяются по массиву из SMP-узлов.

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

По аналогии с процессорной архитектурой стоит отметить, что к горизонтальному масштабированию также может применяться симметричный или асимметричный подход. В качестве иллюстрации последнего можно привести разбиение на основе сервисов, когда, например, каталог продукции располагается и обслуживается одним сервером БД, складской учет ведется на другом, корзины покупателей – на третьем и т.д. Промежуточный бизнес-слой «знает», к какому серверу обращаться по какому вопросу. Другая стратегия разбиения предполагает, что по узлам распределяются большие таблицы независимо от того, к какой БД/сервису они относятся. Этот подход носит более симметричный характер. Как бы то ни было, помимо разбиения, горизонтальное масштабирование ставит в более сложные условия процессы управления и администрирования массивов серверов, но имеет при этом следующие преимущества по сравнению с «монолитными» системами.

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

Далее в докладе будут разобраны детали реализации и показатели производительности симметричного горизонтального решения на примере федерации серверов SQL Server 2005 для обслуживания сайта MSN.