about NetApp

Приходящим с opennet.ru по некорректно озаглавленной ссылке: эти статьи НЕ про оптимизацию произвдительности систем хранения в целом, а про специальные инструменты и средства оптимизации производительности конкретно систем NetApp FAS! Если у вас не NetApp FAS, то вам, кроме вот этой первой статьи, будет неинтересно!

С неделю уже закопался в материалы по оптимизации производительности систем хранения, причем не только NetApp, но, все же, главным образом. И решил подкинуть вам полезных сведений, тем более из опыта знаю, что множество админов систем хранения NetApp, увы, имеют, зачастую, самые базовые представления об диагностике и траблшутинге проблем производительности. И это при том, что, зачастую, системы хранения, даже в базовой поставке, не считая всяких мегакрутых штук типа DFM и Performance Advisor, имеют достаточно средств “загрузить” среднего админа мыслями.

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

1. В первую очередь проверьте все уже известные проблемы (known issues) с софтом и оборудованием, которые часто перечисляют вендоры в документации и release notes. Вполне возможно, что ваша проблема с производительностью имеет хорошо известную причину и, соответственно, решение.
2. Рассматривайте всю систему целиком. Не занимайтесь ускорением “на 5%” отдельно взятых подсистем ее, когда, возможно, куда большие “затыки” существуют на других участках. Выбирайте как цель оптимизации наиболее существеные в общей картине участки системы. Низкое быстродействие IT-системы в целом далеко не всегда вызвано только лишь невысокой производительностью хранилища базы данных.
3. Измеряйте и переконфигурируйте систему поэтапно.  Не пытайтесь объять необъятное и поменять сразу все. Разделите рассмотренную вцелом систему на компоненты, оцените вклад в производительность на каждом этапе, и улучшайте производительность постепенно, начиная с участков, дающих наибольший вклад.
4. Делайте изменения в конфигурации по одному за раз. Если вы найдете причину и улучшите производительность системы, то, если изменений делалось много за раз, будет непросто найти что именно дало результат.
5. Продумайте и распишите по шагам все процедуры изменений, и, что не менее важно, “путей отступления”, “отката” в исходное состояние в случае неудачи. ДО того, как вы начнете что-то менять!
6. Не твикайте систему только ради того, чтобы потвикать! О-о… Даже и комментировать не стану :)
7. Помните про “Закон убывающей доходности”. Начиная с какого-то этапа, каждая следующая ступенька относительного прироста производительности будет вам стоить все дороже и дороже.

Правильная настройка системы хранения, и системы в целом, куда входят сервера и ПО, зачастую может дать весьма серьезный результат прироста производительности. Так, например, в TR-3557 приводится вот такая картинка для результатов базы Oracle 10g на HP-UX, работающей по 10G Ethernet NFS, для настроек по умолчанию OS, и для правильных настроек:

Всегда ищите главное, наиболее существенное “бутылочное горло” системы, и начинайте оптимизацию именно с него.

По опыту Тома Гамильтона, Top5 таких “узких мест” для системы хранения это:

1. “Затык” на уровне диска
2. На уровне интерфейса к дискам FC-AL или SAS
3. На уровне процессора контроллера или OS системы хранения
4. “Потолок” сетевой карты или target-адаптера
5. Проблемы настроек tread parallelism на клиенте

В следующих постах я покажу каким образом и с помощью чего можно обнаружить и проанализировать эти bottlenecks, и принять меры по их устранению.