Что может быть хуже, чем потратить шестизначную сумму на дорогостоящую сеть хранения данных (SAN), не соответствующую требованиям или даже совсем ненужную компании?
Быть тем человеком, который порекомендовал сделать это дорогостоящее приобретение.
Я занимаюсь базами данных 19 лет, и большинство из них — оптимизацией производительности. Я начинал еще до того, как применение RAID стало коммерчески оправданным, не говоря уже о сетях SAN. Чаще всего «узким местом» в оборудовании бывает подсистема ввода-вывода. Обычно ресурсы памяти и процессора сервера избыточны, но компании пытаются сэкономить на компонентах ввода-вывода. В последнее время это несоответствие стало еще более выраженным. Закон Мура действует для кремния, а не для вращающихся дисков.
Если бы определить размеры системы SAN или DAS было просто и недорого, большинство серверов баз данных не имело бы карликовых компонентов ввода-вывода. В этой статье я не предложу вам чудодейственного рецепта, с помощью которого можно решить все проблемы ввода-вывода. Но я могу высказать ряд соображений, которые стоит принять во внимание, если вы хотите более эффективно решать задачи ввода-вывода в экосистеме обработки данных.
Во-первых, не всегда требуется расширять полосу пропускания подсистемы ввода-вывода, даже если кажется, что проблема именно в ней. Предположим, все счетчики ввода-вывода зашкаливают. Возможно, это плохо. Но, может быть, они в красной зоне, потому что из-за отсутствия нужного индекса постоянно производится сканирование таблицы, насчитывающей миллиард строк. После добавления индекса сканирование превратится в поиск, а красные кривые на счетчиках — в горизонтальные зеленые линии. Вряд ли затраты на расширение подсистемы ввода-вывода помогут устранить эту проблему.
Во-вторых, кому доверить выбор технических характеристик сети SAN? В большинстве компаний выбором конфигурации и оптимизацией сети SAN ведает поставщик. Для справки: люди, которые продают оборудование с шести- или семизначными ценами, получают солидные коммиссионные. Это не означает, что они продают то, в чем клиенты вовсе не нуждаются, но чем дороже проданное оборудование, тем больше их заработок.
В-третьих, кто составляет схему SAN и определяет, как будут выглядеть диски? Обычно это поставщик. Это скользкая тема. Я не предполагаю, что типичный системный инженер поставщика сетей SAN не знает своих продуктов и технологии. Обычно это опытные профессионалы. Но, к сожалению, у них недостаточно знаний о базах данных. Структура сети хранения данных, определенная поставщиком SAN, часто оказывается не самой подходящей для рабочей нагрузки от базы данных.
В-четвертых, предположим, что нам действительно требуется увеличить пропускную способность каналов ввода-вывода. Сеть SAN не всегда оказывается правильным выбором. Чрезвычайно полезные функции управления обеспечивают высокую гибкость сетей SAN, но с учетом всех факторов пропускная способность ввода-вывода DAS почти всегда значительно выше, а затраты — ниже. Кстати, за 19 лет работы консультантом я научился избегать слов «никогда» и «всегда». Употребляя выражение «почти всегда», я подразумеваю, что в ближайший миллиард лет производительность сетей SAN ни за что не превзойдет показателей правильно настроенного решения DAS. Но я не скажу этого прямо, так как стараюсь избегать слов «никогда» и «всегда», давая технические рекомендации.
Брайан Моран (bmoran@solidq.com) — редактор журнала SQL Server Magazine, имеет сертификат MCDBA и SQL Server MVP