Экскурсия в тренды цифровой трансформации в госуправлении в России
Для поиска и устранения узких мест в производительности корпоративных систем хранения данных, которые могут засорить порты, контроллеры и дисковые накопители, требуется сочетание инструментов и опыта ИТ. В нашей статье пойдет речь, как устранять наиболее распространенные узкие места в хранилище и как их избежать.
Наиболее частыми местами возникновения узких мест и проблем с производительностью системы хранения данных являются внешние порты в массиве хранения, контроллеры и диски. Задача состоит в том, чтобы выяснить, какие точки перегрузки вызывают плохую работу приложения, и проблема ли вообще в хранилище.
Технология виртуальных серверов может усугубить проблему, увеличивая вероятность чрезмерно загруженных ресурсов, особенно если связь между администратором приложения, сервера и хранилища плохая.
Существуют инструменты для определения узких мест в производительности системы хранения. К ним относятся менеджеры элементов, встроенные в массивы хранения, более сложное программное обеспечение для управления ресурсами хранения (SRM) или специализированные приложения для мониторинга производительности, такие как BalancePoint от Akorri Network Inc. и Profiler от Tek-Tools Software Inc. Но ни один из этих инструментов не поможет, если вы не знаете, где искать.
5 распространенных причин, создающих узкие места производительности хранилища данных
Ниже приведены наиболее распространенные причины возникновения узких мест в системе хранения данных.
1. Виртуальные серверы сейчас очень популярны, но они также создают большое количество новых и различных причин для появления узких мест хранения. Настройка среды виртуального сервера со слишком большим количеством виртуальных машин (ВМ) на хранилище данных — распространенная ошибка, приводящая к возникновению узких мест. Другая причина связана с перемещением виртуальных машин с одного физического сервера на другой.
Используя современные технологии, ИТ-организации обычно перемещают виртуальные машины вручную с помощью утилит поставщика или автоматически с помощью функции распределенного планирования ресурсов (DRS). Администратор может обнаружить, чтобы какой-либо отдельный сервер не превышает 60% использования ЦП или 75% использования памяти, и, если это произойдет, может перебалансировать виртуальную машину или переключить ее на менее загруженный сервер. Когда виртуальная машина перемещается на другой хост-сервер, она может получить доступ к хранилищу через другой LUN, который другой хост использует для доступа к хранилищу.
Системным администраторам следует учитывать количестве виртуальных машин, которые они могут поддерживать на порт массива, а также о производительности чтения / записи диска, поскольку виртуальные машины могут выполнять различные типы запросов в зависимости от приложений, которые они запускают. Одна или две особенно загруженные виртуальные машины на любом физическом сервере могут потреблять большую часть ЦП, памяти, пропускной способности сети и дискового ввода-вывода.
Если одна или две виртуальные машины работают с приложениями с интенсивным вводом-выводом и загружают диск, другие виртуальные машины, использующие то же хранилище данных, могут пострадать от конфликтов ввода-вывода на диске. Часто эту проблему выявить труднее, чем перегруженный процессор или память.
2. Когда многие пользователи совместно используют доступ к бизнес-приложению, будь то сервер электронной почты, систему планирования ресурсов предприятия или базу данных, запросы могут накапливаться в очереди. Время отклика для каждого ввода-вывода начинает увеличиваться, короткие задержки превращаются в утомительное ожидание, и следуют звонки в службу поддержки.
Общий профиль для такого чувствительного времени ответа приложения — это множество запросов, случайных по своей природе, больше операций чтения, чем записи, все размеры ввода / вывода. Оптимально, чтобы рабочая нагрузка распределялась по множеству дисков. В противном случае может возникнуть узкое место.
Если приложение добавляет больше пользователей или если приложение разрастается и требует большего количества операций ввода-вывода в секунду, вероятно, потребуется добавить больше дисков в группу RAID, или данные, возможно, придется распределить на другом уровне по большему количеству дисков.
3. Приложения с интенсивным использованием полосы пропускания — такие как резервное копирование данных, потоковая передача / редактирование видео или ведение журнала безопасности — которые, как правило, имеют несколько пользователей, одновременно обращающихся к большим файлам или потокам данных, сталкиваются со своей долей узких мест.
Чтобы изолировать место неисправности, администраторам следует начинать с серверов резервного копирования и постепенно переходить к дискам, поскольку проблемы могут возникнуть где угодно на этом пути.
Если узкое место связано с хранилищем, это может быть вызвано недостаточным количеством дисков для обслуживания операций ввода-вывода, конфликтом на контроллере или неадекватной полосой пропускания на интерфейсных портах массива.
Производительность должна быть настроена для различных типов рабочих нагрузок приложений. Настройка для больших файлов и производительности потоковой передачи не оптимальна для небольших файлов и наоборот, настройка на высокую производительность небольших файлов не лучшая для больших файлов и производительности потоковой передачи.
4. Сбой диска в группе RAID. Производительность снижается, особенно при использовании сценария RAID 5, поскольку система ищет данные четности для восстановления. Операция восстановления влияет на производительность больше при записи, чем при чтении.
Даже если неисправный диск был исходной причиной сбоя, контроллер может стать узким местом, поскольку он продолжает попытки обслуживать данные во время процесса восстановления. После завершения перестройки производительность вернется в норму.
5. Загружается новое приложение, и представленные тома находятся на тех же дисках, которые обслуживают загруженную систему электронной почты. Если новое приложение будет загружено, производительность почтовой системы пострадает. Дополнительный трафик в конечном итоге может перегрузить диски.
Выявление узких мест в стеке программного обеспечения современного СХД
Иногда падение производительности из-за узких мест происходит из-за самого программного обеспечения. В некоторых случаях программы могут быть созданы для одновременного выполнения только ограниченного числа задач, поэтому программа не будет использовать какие-либо дополнительные ресурсы ЦП или ОЗУ, даже если они доступны.
Наиболее частыми случаями проблем приложений являются транзакции, которые загружают базу данных и / или различные системные ресурсы: статический контент, аутентификация, пулы соединений, неоптимизированные должным образом. Во многих случаях конфигурации сред приложений, таких как веб-сервер выполняются с настройками по умолчанию, которые плохо реагируют на трафик пиковой нагрузки.
Где могут возникнуть узкие места?
Хотя для устранения узких мест в системе хранения данных предприятия может потребоваться сочетание инструментов хранения и ИТ-опыта, определение наиболее распространенных областей узких мест в системе хранения данных может быть первым шагом в их устранении.
Ключевые показатели для мониторинга
Наиболее часто в мониторинге упор делается на пропускную способность и измеряется время отклика. Например, время отклика может составлять 4 мс для дисков Fibre Channel со скоростью 15 000 об / мин, 5–6 мс для дисков SAS, около 10 мс для дисков SATA и менее 1 мс для твердотельных накопителей.
Помимо времени отклика, необходимо отслеживать другие ключевые показатели:
- Глубина очереди, или количество запросов, удерживаемых в очереди одновременно; средняя длина дисковой очереди;
- Средний размер ввода-вывода в килобайтах;
- IOPS (чтение и запись; случайное и последовательное; среднее значение общего IOPS);
- Пропускная способность в мегабайтах в секунду;
- Процент записи против процента чтения;
- Емкость (свободная, использованная и резервная).
Узкие места в производительности корпоративных систем хранения данных можно устранить с помощью набора инструментов, связанных с хранением данных, включая инструменты операционной системы, программного обеспечения SRM, приложения для мониторинга SAN и многого другого.