Я заметил, что мой новый EMC VNX5200 SAN имеет тенденцию работать лучше после «вжигания» раздела. Под этим я подразумеваю заполнение раздела разными мусорными данными и удаление всего несколько раз. Спросил об этом моего администратора SAN, но он не хочет беспокоиться. Он пробормотал что-то о IOPS, также заявив, что МБ/с не имеет значения. Теперь, может быть, это так, но для меня очень важно, чтобы мои ночные резервные копии и восстановления SQL (большие непрерывные фрагменты) работали на текущих 80 МБ/с вместо 15 МБ/с, с которых я начал. Настоял и получил свой собственный LUN для сервера SQL. Но я не имею представления о том, сколько дисков на бэкэнде, конфигурации RAID или есть ли на них какие-либо другие LUN, выполняет ли SAN какое-либо кэширование или перемещение часто используемых данных в какое-то более быстрое хранилище (может объяснить «вжигание»). Я мог бы покопаться в консоли администратора, поскольку у меня есть доступ, но я не знаю, как прочитать всю эту информацию.
Я был бы рад узнать, что все работает хорошо, и принять текущую производительность как ожидаемый уровень. Но опять же, максимальная скорость чтения, которую я вижу на этом дорогом SAN-банкомате, составляет 80 МБ/с, а скорость записи — примерно в два раза меньше, что намного ниже моей 3-летней настольной лаборатории с дисками на 7200 об/мин (без RAID), которые могут вытягивать постоянную скорость резервного копирования 110 МБ/с.
Вопрос в том, как добиться стабильной производительности SAN? Что мне следует спросить у моего администратора SAN? Как лучше всего проверить производительность? Или есть ли надежный онлайн-ресурс, где я могу проверить и указать ему базовые показатели производительности, учитывая производителя SAN, модели дисков и данные конфигурации, а также сценарии типа нагрузки? (что-то вроде оценок CPU+GFX для идентичных игровых платформ)
решение1
Ваш администратор хранилища не раскрывает вам всю историю. IOPS — это то, чем вы будете ограничены при выполнении обычного ввода-вывода (случайное чтение с поиском и запись небольших блоков), однако вы правы, что резервное копирование должно представлять собой большое последовательное чтение и не может быть продуктивно измерено в IO/s.
Когда вы делаете резервное копирование, вы читаете непрерывно или делаете много небольших чтений по всему диску? Если это случайные чтения, это снова наложит ограничение на способность дисков к поиску, которая измеряется в IO/s.
Если предположить, что это непрерывные чтения, скорость будет ограничена уровнем передачи в первую очередь — если вы используете iSCSI 1 Гбит/с, у вас максимальная скорость около 80 МБ/с. Если вы используете общую сеть и у вас меньше полной ссылки, то еще меньше. Если ваш порт интерфейса хранилища делает резервные копии для более чем одного клиента, это также может вас ограничить. Наконец, если используемые вами диски используются совместно с кучей других клиентов, которые также выполняют интенсивное чтение или запись, это может вызвать это.
Тем не менее, ваш специалист по хранению должен быть в состоянии, по крайней мере, сказать вам, почему вы работаете так медленно, чтобы вы могли разработать способ повышения производительности. Вы можете попробовать переместить окно резервного копирования, чтобы избежать конкуренции за общие ресурсы, или вы можете отделить свое хранилище, чтобы оно не конкурировало за тот ресурс, который вы в данный момент задыхаетесь.