Мне поручено определить политики SAN для внешней организации. Я не системный администратор, это не системы, над которыми мы имеем власть. Я также не эксперт по SAN. Кто сказал, что работа должна иметь смысл?
Я придумал несколько пунктов, основанных на документации, предоставленной вовлеченными поставщиками (которые внешняя организация, которая в настоящее время будет использовать SAN, не позаботилась изучить). Такие вещи, как «не помещайте тестовое хранилище с большим количеством операций ввода-вывода в один сегмент с хранилищами данных Prod», которые кажутся очевидными, но явно не такими.
Какие-либо рекомендации по общим соглашениям SAN, которые должны быть на месте для повышения производительности и надежности?
В зависимости от нашей конфигурации (оборудование EMC, DB2) у меня есть следующие ключевые элементы:
Прежде чем писать политику, было бы полезно знать, для чего вы пытаетесь определить политику. Это для оптимальной производительности? Защита данных? Что-то конкретное в отношении политики удержания компании? Можем ли мы предположить, что это просто общий документ о характеристиках / надежности на основе вашего заявления?
Причина, по которой я спрашиваю, заключается в том, что SAN (как и любое сетевое оборудование) обычно настраивается в соответствии с ролью. Его конфигурация оборудования может сильно повлиять на рекомендации, которые можно сделать для него. Например, логические модули SQL обычно лучше всего подходят, когда они состоят из множества быстрых дисков (зависящих от шпинделя), тогда как что-то вроде общих ресурсов пользователя или архивных данных лучше подходит для больших и медленных томов (вы, кажется, знаете об этом). Тем не менее, мне было бы трудно окончательно определить уровень RAID, поскольку разные поставщики имеют разные взгляды на него. Например, EMC может посчитать RAID10 предпочтительным, тогда как NetApp считает, что RAID 6 с 24 веретенами является идеальным.
Обычно я бы сказал:
Будет сложно дать вам что-то большее, кроме этих очень общих вариантов, потому что вы начнете получать рекомендации по поставщикам, оборудованию и приложениям. Вы также узнаете о безопасности и политике компании. Вы, вероятно, добьетесь большего успеха в определении требований для конкретного приложения, чем в создании общего руководства по SAN.
Каждый LUN должен быть распределен по шпинделям на серверной части целевых устройств хранения, но, возвращаясь к интерфейсным адаптерам, возможный спрос (# обменов * размер обменов * количество серверов) должен быть сбалансирован. Например, если я не изменю свои серверы, они, вероятно, будут иметь глубину очереди 254. Если мои обмены составляют 4 кадра каждый (8k), то каждый из этих серверов может подавить 2k FA. Я бы хотел сбалансировать свою SAN, чтобы общая возможная нагрузка и возможная нагрузка в определенные моменты времени (резервный трафик попадает, когда дневной трафик не работает). Не стесняйтесь определять пределы QueueDepth и ловить тех, кто их превышает. Если вы не знаете, как ловить нарушителей QD, я могу вам показать.
Я бы также попытался применить политику: если вы не используете SAN, вы не будете зонированы, и ваш порт будет отключен. Многие среды предоставляют SAN всем серверам, но они не сразу (никогда?) Подключаются к SAN. Тем не менее, они имеют тенденцию к быстрому включению / выключению / включению / выключению / включению / выключению, и именно эти устройства вызывают бурю обновлений по фабрикам. Давайте задушим их, прежде чем они станут проблемой.
Поместите устройства в VSAN по умолчанию / шасси или VF: VSAN0001 на Cisco или VFAB128 на Brocade. Когда пользователь решает, где должен быть порт, переместите его в VSAN или VF. VSAN0001 или VF128 не передают ISL / XISL - это снижает риск широковещательного шторма.
В новых устройствах запрашивающая сторона должна указывать, являются ли они однонаправленными или многолучевыми, а если многолучевые, являются ли они активными, пассивными, сбалансированными многопутевыми или несбалансированными многопутевыми, чтобы, когда они не сбалансированы, вы могли видеть возникла проблема с конфигурацией или неправильно работали инструменты с несколькими путями.
Назови все. Псевдонимы помогают. Имейте схему именования, чтобы Oracle14_HBA0 заставлял вас ожидать Oracle14_HBA1. Это помогает при возникновении проблемы: вы можете решить, стоит ли Oracle14_HBA0 вставать с постели прямо сейчас или подождать до следующего рабочего дня.
Требовать от отправителей запроса запрашивать хранилище с точки зрения задержки (мс) по запросу (МБ / с или IOPS). Они захотят сказать: «Tier1! Tier1! Мои вещи потрясающие, мне нужен Tier1», не зная, что это такое. Настаивайте на SLA, например «40 мс для 200 МБайт / сек», что является довольно простой задержкой при однопутевом канале 2 ГБ. Если они не знают, скажите им «40 мс @ 200 Мб / сек» и подождите, пока они подтвердят. В конечном итоге они перейдут на 9 мс для логических модулей журнала намерений базы данных, но не сразу, и у вас будут безумно дорогие логические модули с поддержкой Flash с помощью SAS только для тех мест, где они нужны.
Ограничение скорости VMAX - ваш друг: подавите всплеск спроса, прежде чем он переведет ваш массив в состояние ожидания записи. См. Выше: «40 мс @ 200 МБ / с».
Это некоторые мысли, основанные на обучении FibreChannel до 50 человек одновременно и выяснении их проблем.
Другие уже давали советы, я добавлю несколько собственных предложений:
Каждый сервер должен иметь два физически различных пути к хранилищу. Это означает, что два HBA-адаптера на сервер проходят через два полностью отдельных набора коммутаторов SAN на двух разных фабриках с двумя разными внутренними контроллерами. Не экономьте и покупайте двухпортовый HBA-адаптер - это дает полосу пропускания, но не обеспечивает отказоустойчивость. (Если возможно, используйте для оптоволоконных кабелей разные физические маршруты через серверную).
Многопутевое все. Как минимум два пути, добавьте еще, если вам нужна лучшая производительность.
Используйте псевдонимы для HBA и контроллеров. Zone к этим псевдонимам. Придерживайтесь зонирования с одним инициатором. Вероятность возникновения проблем меньше всего, если вы не полностью понимаете последствия. Назовите свои зоны в зависимости от того, что они содержат. При желании можно включить логическую группировку в имя зоны. (например, oracle_clus2_hostname_HBA0_array_port4)
Спросите о производительности, ожидайте ответа «не знаю» или «много!» введите ответы. На этот вопрос редко можно получить хороший ответ, но он важен в среде консолидированного хранилища. Вся суть консолидации состоит в том, чтобы получить лучшую пиковую производительность и более низкое среднее значение - это подходит для большинства рабочих нагрузок, потому что операции, выполняемые «лицом к лицу», больше заботятся об ответе одной транзакции (и не заботятся о том, что она простаивает).
Не зацикливайтесь на типах RAID - это может быть отвлекающим маневром. Кэширование имеет большее значение, чем типы RAID, и кэширование по-разному влияет на разные виды рабочих нагрузок.
Чтение ввода-вывода находится под жесткими временными ограничениями - для завершения чтения на хост массив имеет для получения блока с диска. Кеширует предварительную выборку и пытается угадать, что будет нужно дальше, поэтому предсказуемое чтение ввода-вывода выполняется быстрее, чем случайное.
Запись ввода-вывода находится в условиях мягкого ограничения по времени - вы можете записывать в кеш и подтверждать запись на хост - а позже удаляться на диск. Это означает, что вы можете делать некоторые приятные вещи, такие как объединение записи и запись с полным чередованием, и значительно сокращают «накладные расходы» от типа RAID. При последовательной рабочей нагрузке, такой как журналы / журналы, в результате RAID-5 может быть быстрее, чем RAID 1 + 0.
Часто используется термин «штраф записи» - сколько дисковых операций требуется для «завершения» записи [1].
Это означает, что для чистой рабочей нагрузки произвольной записи вам необходимо разделить теоретические полезные IOP на шпиндель (~ 150 для FC, ~ 75 для SATA) на этот штраф за запись.
Для всех типов рейдов «штраф за чтение» в основном одинаков - вам нужно завершить чтение откуда-то в вашем массиве. Вы получаете небольшое преимущество от RAID1, потому что он может быть прочитан из двух разных мест и посмотреть, какое из них отреагирует быстрее, но в этом не так много - диски все равно должны вращаться и искать.
С объединением полос, которое большинство массивов может выполнять с последовательной записью, вы можете сократить штраф за запись. Если у вас есть вся полоса четности для вашего RAID 5, например - вам не нужно считывать четность, вы можете вычислить ее из того, что находится в вашем кеше. В этом случае штраф за запись снижается до 1+ 1 / размер Raidgroup, поэтому для группы 4 + 1 RAID 5: 1.25. Это означает, что это лучше чем RAID 1 + 0 для устойчивых рабочих нагрузок последовательной записи. (например, журналы базы данных)
Устойчивость - у вас есть несколько разных расчетов, но я все же сказал бы - не слишком зацикливайтесь на типах RAID и здесь - вы получите сложные сбои, если у вас достаточно большой временной интервал, поэтому здесь нет необходимости в достойном решении для восстановления. Между типами RAID есть различия в устойчивости, но единственный, который вам точно не стоит использовать, это RAID0 :).
(Существуют и другие настраиваемые типы RAID. Например, NetApp использует то, что они называют RAID-DP для двойной четности. Это в основном RAID-4 с дополнительным шпинделем четности, но из-за того, как NetApps используют свою файловую систему WAFL, на самом деле имеет очень низкий уровень записи штраф)