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, и принять меры по их устранению.