(Возврат на основную страницу)
Ларри Зельцер (Larry Seltzer)
В течение многих лет мне приходилось быть свидетелем постоянных споров о том, «достаточно ли быстры компьютеры». Наконец я согласился с этой точкой зрения в отношении среднего настольного компьютера бизнес-класса. Но что касается серверов, в приложении к ним слово «быстрее» все равно означает лишь некоторое повышение производительности, и достичь этого повышения непросто.
Помимо банального периодического повышения тактовой частоты процессоров, есть два альтернативных пути достижения так называемого «параллелизма». Во-первых, это повышение мощности серверов путем наращивания числа процессоров и объема памяти на каждом сервере и, во-вторых, разделение нагрузки между большим количеством более дешевых серверов, объединенных в сеть. Можно даже сконструировать кластер, состоящий из многопроцессорных систем высокого уровня, что, впрочем, будет довольно экстравагантно, но вполне объяснимо, если вы являетесь агентом NSA*.
В компьютерах с классической архитектурой ОС распределяет процессорное время среди различных программ и образующих их потоков. В кластере систем, специализированных для работы с некоторым приложением, система распределяет процессорное время для работы с программой между отдельными компьютерами кластера. Но поскольку в любой ОС масштабировать обычное приложение для работы больше, чем на нескольких процессорах, чрезвычайно трудно, то в системах очень высокого уровня для масштабирования ПО используются другие методы.
Современные ОС, внедряемые на действительно громадных серверах, поддерживают разделение нагрузки между процессорами. Это означает, что определенные приложения привязаны к определенным процессорам или хотя бы имеют приоритетный доступ к ним. Почти всегда при использовании серверов с 16 и более процессорами (например в случае баснословно дорогих систем Sun E1000) можно предполагать, что именно процессоры распределяются между специфическими приложениями, а не используются для исполнения одного конкретного экземпляра или конкретного приложения.
IBM использует другую методику, реализованную на мэйнфреймах под управлением Linux, — виртуальные машины (ВМ). Несмотря на то, что Linux изначально является многопользовательской ОС, в таких системах IBM предпочитает исполнять несколько экземпляров Linux — в отдельной защищенной виртуальной машине каждый. Причин этому две. Во-первых, даже если один из экземпляров ОС «рухнет» (хотя все знают, что в Linux не бывает крахов), остальные продолжат работу как ни в чем не бывало. И что важнее всего, архитектура ВМ позволяет масштабировать ОС лучше, чем средства самой ОС. Частично это определяется ограничениями ОС Linux, но для достижения высокой производительности многопользовательской ОС также необходима рациональная конструкция серверных приложений. Производительность нерационально написанного серверного приложения снизится, как только число пользователей превысит несколько человек. Но и в этом случае возможна поддержка большого числа пользователей путем исполнения нескольких экземпляров такого приложения. IBM также утверждает, что производительность виртуальных машин повышается при консолидации нескольких серверов, рассчитанных на небольшую нагрузку. Например, при объединении брандмауэра с серверами DNS и удаленного доступа их производительность будет выше по сравнению с аналогичными отдельно работающими серверами.
Экономисты IBM не рассматривают масштабирование в отрыве от консолидации. Однако решение проблемы достижения адекватной производительности в таком окружении требует больше, чем простое наращивание памяти и числа процессоров, а именно — комплексного планирования. Для примера рассмотрим, как отразится на сетевом трафике консолидация 25 серверов в один большой мейнфрейм под управлением Linux. С одной стороны, большая часть обычного межсерверного сетевого трафика становится внутрисерверным трафиком между процессами или отдельными виртуальными машинами, поэтому его стои- мость «оплачивается» локальными ресурсами процессора и памяти. С другой стороны, для обмена данными было необходимо минимум 25 сетевых интерфейсов. Сколько их потребуется для нового консолидированного сервера?
Не думаю, что человек в состоянии ответить на подобный вопрос, касающийся большой системы. Это задача специальной программы для моделирования. В IBM имеются собственные инструменты конфигурирования для определения размера серверов. Также в этой связи можно упомянуть CIOView, компанию, продающую очень дорогие инструментальные средства, которые не только помогают определить верную конфигурацию для переноса (на основе стандартных значений, например TPC, или собственных метрик клиента), но и пытаются оценить значение TCO для каждого конкретного случая.
Помимо прочих задач консолидации, хотелось бы знать, какие типы приложений лучше масштабируются в многоуровневых системах, а какие — в одноуровневых. Для ответа потребуется слишком сильное обобщение, но он все равно нужен, не так ли? Для повышения производительности больших приложений, сконструированных как единый образ (например Oracle или Microsoft SQL Server), скорее всего, понадобится более мощная система. Многопользовательские приложения, не меняющие своего состояния в процессе работы (например большие Web-серверы), очень хорошо масштабируются в больших кластерах, состоящих из множества отдельных систем. Например, я не знаю, сколько серверов обеспечивают работу узла www.microsoft.com, но думаю, что довольно много. Между прочим, для распределения между серверами нагрузки по обслуживанию этого узла Microsoft, вероятно, использует то, что называется балансировкой нагрузки на сеть (Network Load Balancing, NLB). Microsoft считает NLB частью служб Windows Clustering Services. С определенной натяжкой примером «кластерной» технологии можно считать DNS, которая решает сходные задачи, несмотря на все свои отличия.
В Microsoft мне сказали, что у них есть клиенты, работающие над решением одной и той же вычислительной задачи при помощи сотен систем одновременно, например при помощи кластера из 1024 машин. Если рассматривать проект SETI@Home, совершенно понятно, что данное приложение может быть масштабировано в системе, число компонентов которой намного превышает 1024, хотя не совсем ясно, как в этом случае удается реально привлекать ресурсы всех машин.
Я склонен верить, что рынок достаточно велик для систем, использующих как тот, так и другой подход. Они оба имеют смысл. Хочу сказать, что, какие бы подходы не рассматривались, меньше всего проблем с внедрением вызовет тот, рентабельность которого не вызывает сомнений. В других случаях следует убедиться в экономической эффективности избранного подхода, поскольку риск непредсказуемых затрат здесь больше.
Порочная практика — БД (и не только), чувствительные к регистру символов
Энди Уоррен (Andy Warren)
Это четвертая статья из серии. Первые три были опубликованы в №№ 1–3.
Мы уже рассмотрели ряд интересных вопросов и получили много одобрительных отзывов от наших читателей. Здесь я хотел бы обсудить один вопрос, предложенный Майнди Кернаттом (Mindy Curnutt), нашим читателем и по совместительству автором: стоит ли делать всю БД чувствительной к регистру символов? Кто поспорит, что чувствительность к регистру усложняет программы? Независимо от языка, написание хороших программ само по себе является слишком непростой задачей, чтобы дополнительно усложнять ее этой проблемой.
Но прежде чем заклеймить использование чувствительности к регистру как совершенно непригодный прием, давайте рассмотрим причины, побуждающие к ее использованию. Допустим, вы работаете с приложением, чувствительным к регистру. То есть, при просмотре таблицы в поисках кода штата Флорида значения «FL» и «Fl» для него — не одно и то же. Но как нам найти только код Флориды? Естественно, путем создания уникального индекса! Теперь аналогичный запрос вернет FL или Fl, но не оба значения сразу. Даже если приложение чувствительно к регистру, не нужно делать таким столбец, таблицу или БД. Или такая необходимость все же есть?
А что, если в таблице уже есть значения, не позволяющие добавить уникальный индекс (чувствуете, с какой болью я спрашиваю? Это жизненная ситуация!)? Что ж, тогда придется сдаться и обратиться к использованию данных, чувствительных к регистру? Мне это совсем не нравится, поэтому давайте рассмотрим другую идею. Можно запрограммировать триггеры на вставку и обновление, выполняющие проверку чувствительной к регистру таблицы и откатывающие все изменения, которые нарушают наше условное «правило», не допускающее добавления «дублирующихся» записей. Иначе говоря, не стоит дополнительно усложнять проблему!
Франческо Балена (Francesco Balena)
Статья предполагает, что вы знакомы с SQL Server и Visual Basic.
SQL Server можно администрировать программно, с помощью системных хранимых процедур, однако есть и более современная и объектно-ориентированная альтернатива — модель Distributed Management Objects (DMO, объекты распределенного управления). Мы рассмотрим объектную модель SQL-DMO в SQL Server 7.0 и SQL Server 2000, а также обсудим ее деревья Databases и JobServer. В прилагаемом к статье архиве показана автоматизация различных административных задач (программное чтение конфигурационных параметров, создание новых БД, выполнение сценариев T-SQL, планирование и выполнение резервного копирования и т. д.) с помощью таких объектов, как Registry, Configuration, Database и др.
В SQL Server имеется постоянно развивающийся набор системных хранимых процедур для автоматизации различных административных задач: создания БД и таблиц, необслуживаемого резервного копирования и т. д. Однако раньше для полноценного использования этих процедур требовались довольно глубокие знания T-SQL. С появлением объектов DMO административные задачи можно выполнять с помощью любого языка программирования.
SQL-DMO — это набор из приблизительно 150 объектов, охватывающий практически все аспекты управления SQL Server 7.0 и SQL Server 2000. Полное дерево объектов SQL-DMO приведено в SQL Server 2000 Books Online (см. раздел «SQL-DMO Objects Tree»). Объектная модель SQL-DMO включает полную поддержку двойных интерфейсов, и поэтому ее можно использовать практически в любом языке программирования, включая Visual Basic, C++, VBScript, Windows Script Host (WSH) и ASP-сценарии. К статье прилагается несколько фрагментов кода, а также законченные приложения, демонстрирующие программное чтение конфигурационных параметров, создание новых БД, выполнение сценариев T-SQL и планирование резервного копирования. Код написан преимущественно на Visual Basic, но его можно легко преобразовать в любой другой язык программирования.
Энди Уоррен (Andy Warren)
Держу пари, что каждый, кто поработал с Access или SQL хотя бы несколько часов, знает, для чего нужны столбцы типа autonumber/identity и насколько они полезны для создания «бессмысленных» первичных ключей.
Создание столбца с идентификатором никогда не вызывало затруднений: это просто столбец с целочисленными значениями, удобными для индексирования. Однако незадачливого пользователя здесь поджидает несколько трудностей.
Использование уникальных идентификаторов (uniqueidentifier) — полезный прием, позволяющий избежать подобных проблем. Для тех, кто не знаком с этим типом данных, поясню: uniqueidentifier — это гарантированно уникальное 16-байтовое значение, не дублирующееся ни на одном компьютере в мире. В SQL оно генерируется с помощью функции NewID(). Хотя мне так и не удалось найти точные сведения о способе генерации значения uniqueidentifier, в материалах MSDN говорится, что оно создается из комбинации MAC-адреса сетевой платы, текущей даты и времени и, возможно, ряда других значений. Обычно уникальный идентификатор выглядит так:
‘6F9619FF-8B86-D011-B42D-00C04FC964FF’
Однако у этого типа данных есть ряд очевидных недостатков. Первый — большая длина значения: 16 байтов против 4 у типа данных int, что несколько снижает производительность. Кроме того, думаю, что людям будет труднее с ними работать (вообразите, что вы просите сослуживца проверить заказ под номером ‘6F9619FF-8B86-D011-B42D-00C04FC964FF’).
Если столбец с уникальным идентификатором нужно заполнить автоматически, подобно обычному, установите для этого столбца умолчание NewID(). В SQL 2000 можно установить свойство IsRowGuid с помощью ЕМ, при этом умолчание NewID() будет добавлено автоматически (у меня не было возможности проверить это в SQL 7.0). Такое умолчание позволяет SQL уникально идентифицировать строку значением типа uniqueidentifier. Эта ситуация несколько отличается от той, когда такой же столбец делают первичным ключом. Если при настройке репликации сведением столбец с уникальным идентификатором не пометить как rowguid, к таблице будет добавлен еще один столбец с уникальным идентификатором.
Бред М. МакГи (Brad M. McGehee)
Цель этой статьи — ознакомить вас с кластеризацией SQL Server, ее достоинствами и недостатками. Если вы рассматриваете кластеризацию SQL Server как средство снижения потенциального времени простоя, то эта статья — хорошая отправная точка.
Если на сервере, где стоит SQL Server, от которого зависит деятельность всего вашего предприятия, выйдет из строя материнская плата, как долго он не будет работать? Час, четыре часа, день или дольше? Сколько потеряет ваш бизнес из-за снижения количества продаж или производительности? И, что, наверное, даже более важно для вас, какой уровень нагрузки из-за этого придется выдержать вам?
Быть администратором SQL Server — напряженная и ответственная работа, особенно, когда успех вашей компании во многом зависит от безотказного функционирования SQL Server. Хотя мы как администраторы БД можем контролировать время безотказной работы наших SQL Server, полного контроля у нас нет. Например, при отказе материнской платы сервера единственное, что мы можем сделать, — подготовиться к этой ситуации.
Как вы уже, наверное, знаете, есть способ увеличить время безотказной работы SQL Server — кластеризация. При отказе одного из узлов кластера, другой автоматически берет на себя его функции, что позволяет значительно сократить время простоя.
Изучаем SQL Server 2000 за 15 минут в неделю: дополнительные возможности установки
Майкл Оберт (Michael Aubert)
В этой статье я расскажу о некоторых дополнительных возможностях установки SQL Server. Предметами обсуждения этой статьи будут:
(Возврат на основную страницу)