Уже в течение 10 лет я участвую в проектах виртуализации. За это время мне удалось составить собственный список рекомендаций, с которым может ознакомиться любой желающий. Судя по количеству обращений, можно с уверенностью сказать, что популярность виртуализации (и «облака») растет, особенно среди пользователей SQL Server.
В сущности, в моем списке собраны ошибки, которые заставляют администратора в ужасе хвататься за голову. Список был полезен моим клиентам, и я уверен, что он пригодится и вам.
1. Самостоятельная сборка
В ИТ-подразделениях часто появляется возможность повторного использования компонентов для тех или иных целей. Иногда это старый монитор, иногда аккумулятор или модули оперативной памяти. Таким образом вырабатывается привычка как можно дольше использовать однажды купленное оборудование. Порой, оглядывая серверную комнату, администратор думает: «Да я из этого соберу настоящий мощный сервер, который может стать хост-компьютером для виртуализации!».
Не стоит разделять подобное заблуждение.
Вы не соберете хост-компьютер — особенно для ПРОИЗВОДСТВЕННЫХ целей — из компонентов серверов с истекающим сроком эксплуатации. Если оборудование уже устарело, представьте, каким оно будет через полтора года. Если вы хотите сократить затраты и использовать запасные части, применяйте их для экспериментальных проектов и приготовьтесь потратить время, чтобы содержать эту груду металла в работоспособном состоянии.
Планируя переход в виртуальную среду, купите новые аппаратные средства для хост-компьютеров. Возможности оборудования должны быть больше, чем у используемых сейчас физических компьютеров. Необходимо также учитывать условия лицензирования. Может оказаться, что дешевле приобрести новое оборудование и сократить круг лицензируемых продуктов.
2. Отсутствие сведений об уровне производительности
Нельзя приступать к виртуализации, не имея представления о приемлемом уровне производительности. Представители VMware утверждают, что производительность может достигать 98 % от текущей физической реализации SQL Server. Это не означает, что вы получите лучшую производительность при переходе на VMware. Часто производительность повышается в результате обновления аппаратных средств (см. предыдущий пункт). Но если вам неизвестны условия текущего соглашения об уровне производительности, то невозможно предсказать, удастся ли соблюсти их после виртуализации. Заранее проверьте свои ожидания, и вы сможете отслеживать показатели по ходу работ.
Определяя базовый уровень производительности, не сосредотачивайтесь исключительно на продолжительности выполнения запросов. Полезно также измерить стоимость логических операций ввода-вывода и процессора. Если вы намерены выжать из хост-компьютеров всю производительность, на которую они способны, то необходимо быстро идентифицировать запросы, потребляющие основные ресурсы процессора и памяти, и настроить их в первую очередь (см. рисунок).
.jpg) |
| Рисунок. Пример мониторинга операций ввода-вывода и нагрузки на процессор |
Существует два основных варианта: тома RDM и формат диска виртуальной машины (VMDK). Какой из них следует использовать и когда? В действительности разница функциональная и архитектурная (я понимаю, что напугал некоторых администраторов словом «архитектурная», но что поделаешь).
VMware опубликовала список сценариев (http://blogs.vmware.com/apps/2011/11/virtualized-exchange-storage-vmdk-or-rdm-or.html), в которых тома RDM будут предпочтительным решением. Необходимо уяснить эти различия, прежде чем начинать развертывать решение, не удовлетворяющее некоторым важнейшим бизнес-требованиям.
Следует также понимать различия между уровнями RAID и знать, какие из них оптимальны для SQL Server. Наконец, помните, что одна из причин популярности виртуализации в том, что общее хранилище позволяет при необходимости без труда перемещать серверы между узлами. Но, с другой стороны, это и большая слабость, так как «беспокойный сосед» может забрать ресурсы, затруднив работу другого сервера, использующего тот же диск. Помните об этом, выбирая конфигурацию дисков.
4. Тонкая подготовка
Тонкая подготовка — одна из тех неудачных идей, которые на первый взгляд выглядят превосходными, но на поверку приводят к таким же результатам, как самостоятельное лечение зубов. Сначала ничто не предвещает беды: кто-то хочет сэкономить место и всего лишь оптимально распределить память. Конечный результат: никто не отслеживает, для каких виртуальных машин выполнена тонкая подготовка, а размер файлов увеличивается до тех пор, пока не будет исчерпана вся доступная область хранилища. Все действия прекращаются, так как диск заполнен.
Общая рекомендация по устранению проблемы заполнения дисков — перенести «гостей» на новые узлы. Замечательный совет, но, полагаю, у многих пользователей изначально не хватает места, в противном случае они не прибегали бы к тонкой подготовке.
Я помогаю администраторам баз данных понять особенности тонкой подготовки по сравнению с авторасширением для SQL Server. Если имеется файл данных большого размера (например, 500 Гбайт), который продолжает увеличиваться шагами по 10 %, то для следующего события роста потребуется 50 Гбайт на диске без предупреждения. Если на диске доступно менее 50 Гбайт, то диск будет заполнен точно так же, как при тонкой подготовке.
Большинство хороших администраторов баз данных принимает меры к тому, чтобы уменьшить вероятность заполнения диска в результате авторасширения с последующими неудобствами для конечного пользователя. Если тонкая подготовка используется для экономии места, то необходимо также предусмотреть дополнительные шаги по управлению средой во избежание внезапного роста.
5. Чрезмерное выделение памяти/процессора
Нет ничего предосудительного в том, что администратор хочет выделить ресурсы памяти или процессора. Но при этом нельзя допустить перегрузки памяти и процессора до такой степени, что начнет явно снижаться производительность.
Просматривая конфигурацию клиента, я называю в качестве ориентира соотношение 1,5:1 в качестве верхнего предела ресурсов центрального процессора (таким образом, наличие 16 логических ядер означает, что можно выделить 24 процессора в качестве базовой линии и понижать или повышать ее в зависимости от рабочей нагрузки и балансировки).
В отношении памяти я следую рекомендациям, данным в руководстве VMware Performance Best Practices: «Избегайте чрезмерного выделения памяти». Словом, мой подход к выделению памяти намного консервативнее, чем к ресурсам процессора.
Легко перейти пределы разумного, выделив слишком много ресурсов при постепенном увеличении числа «гостей» на узлах. В следующий раз, добавляя нового «гостя» на узел, задумайтесь на несколько минут и вычислите верхнюю границу уже выделенных ресурсов памяти и процессора. Благодаря этим минутам в будущем удастся сэкономить часы. Дополнительные сведения о выделении памяти для SQL Server в зависимости от спроса можно найти на сайте Confio LogicalRead (www.confio.com/logicalread/sql-server-demand-based-memory-allocation-w01).
6. Доверие к счетчикам O/S
Виртуализация означает, что между вами и данными на диске появляется дополнительный уровень абстракции (гипервизор). Сложность в том, что надо узнать, какой именно уровень приводит к проблемам с производительностью. Это хост-компьютер? Или «гость»? Необходимо воспользоваться счетчиками производительности виртуальной машины, чтобы получить полную картину происходящего.
Администраторы баз данных знают, что их серверы виртуальные, но жалуются, что не имеют информации о счетчиках производительности Vmware. Без нее невозможно определить, где действительно находятся узкие места. Типичный пример — дефицит ресурсов процессора. В SQL Server могут проявляться симптомы внутреннего дефицита ресурсов процессора, и администратор принимает меры для устранения проблемы. Однако внутренний дефицит может быть результатом проблемы с «гостем» или даже хост-компьютером.
Не зная, где в действительности находится слабое место, администратор тратит время, пытаясь что-то исправить. Очень жаль тратить время напрасно, не так ли?
Если вы по-прежнему используете обычные метрики для виртуального сервера, то идете ложным путем.
7. Запуск всего и сразу
Вернемся к совету избегать выделения всех ресурсов сразу. В этом случае важно знать рабочие нагрузки и особенности балансировки нагрузки. Нельзя разместить десяток «гостей» в качестве производственных серверов базы данных и запускать их в обычные рабочие часы, ожидая при этом, что производительность останется на уровне 98 %, обещанных специалистами Vmware.
Порой балансировка нагрузки — в большей степени искусство, чем наука. Это объясняется тем, что при всех благих намерениях и размещении гостевых серверов на узлах с разделенным временем использования и рабочими нагрузками однажды произойдет нечто, нарушающее цепочку событий. Когда такое событие происходит, быстродействие резко снижается, начинается эффект домино, и может пройти несколько циклов, прежде чем работа вернется в нормальное русло.
Необходимо сбалансировать нагрузку, иначе излишнее выделение ресурсов может превратиться в использование большего количества ресурсов, нежели физически доступно в системе. Недостаточно просто наладить баланс, нужно оставить пространство для роста и расширения.
Тем не менее, приходится наблюдать, как клиенты распределяют ресурсы своих узлов слишком тонко или слишком быстро.
8. Планирование мощности
Говоря «слишком тонко или слишком быстро», я подразумеваю успешное планирование мощности. Теоретически это прекрасная идея, но на практике усилия часто оказываются тщетными.
Можно предположить, что «в предшествующие шесть месяцев рост составил Х процентов, а в следующие шесть месяцев ожидается показатель Y процентов», но в действительности руководство компании может потребовать безупречной загрузки 1000 файлов размером 1 Гбайт.
Другими словами, бизнес-требования будут меняться, часто без предупреждения. Точно так же, как в случае с балансировкой нагрузки, нужно учесть будущий рост в рамках планирования мощности. Нельзя допустить, чтобы все имеющиеся ресурсы (процессор, память, диск, сеть) были задействованы сразу же и по максимуму. Иначе вы очень скоро столкнетесь с проблемами.
Подводим итог
За последние 10 лет технология виртуализации прошла большой путь. Многие подразделения компаний, когда-то считавшиеся совершенно не подходящими для виртуализации, теперь с успехом выполняют виртуализацию своих серверов баз данных. По мере роста числа таких проектов становится очевидно, что перечисленные восемь ошибок являются болевыми точками многих из них.
Эти восемь ошибок приводят к падению производительности и нестабильности. Их легко избежать, если обладать соответствующими знаниями и заранее определить требования.