С балансировщиком именно ЗАГРУЗКИ файлов все просто. Выбираете параметр по которому измерять балансировку. Обычно выбирают такие показатели:
- Среднюю нагрузку в IOPs на дисках сервера за 5-10 минут (где меньше, туда пишем)
- Свободное место на дисках сервера (проверка, можно ли туда писать)
- Объем трафика от ширины канала за 1-3-5-10 минут (IOPs может быть мало, места много, но канал забит на 99%)
Эти параметры собираются в таблицу, скриптом.
Раз в несколько минут срабатывает анализатор, который на основании этих данных выставляет вес каждой ноды для заливки файлов.
А вот если надо балансировать данные между нодами, то тут надо считать нагрузку по чтению, загрузку канала, объем занимаемого места. И уже на основании этих данных выделять горячие ноды с SSD для часто запрашиваемых файлов, средние и холодные. И думать как сделать миграцию на Вашем продуктиве.
Обычно это по ночам, но все зависит от Вашего паттерна нагрузки на файлы.
Для фото объявлений, например, обычно характерна большая нагрузка в первые дня, потом можно перемещать в среднюю зону.
В общем ошибка конкретно в реализации VMWARE VVOL 6.5
Ошибка подтверждена тестами специалистов НР на тестовом стенде :(
Ждем реакцию VMware, пока откатываемся на ESXi 6.0
Шаги:
1) создали 2 CPG (FC_R5 and SSD_R5)
2) создали 2 Virtual Volume (FC_VV and SSD_VV)
3) создали Virtual Volume Set (VV_VVOL) прописали как VVOL контейнер ручками в консоли 3PAR
4) указали на 3par клиентский сертификат и метод подключения, запустили сервис VASA
5) подключили VASA в VCenter 6.5
Все ок.
Создаем VM с политикой хранения default storage policy (VVOL No Requirements Policy).
Все ок, VM лежит на CPG SSD_R5 через VVOL.
Теперь попробуем сменить тип хранения или мигрировать VM.
Создаем 2 VMWare storage policy:
1) SSD Policy, указывает только ОДИН тип CPG = SSD_R5, больше никаких условий и тэгов
2) FC Policy, указывает только ОДИН тип CPG = FC_R5, больше никаких условий и тэгов
Указываем в существующей машине другой тип storage policy и пробуем сделать Reapply storage policy.
1) сначала пробуем SSD Policy
2) потом пробуем FC Policy
В обоих случаях такие варианты ошибок при ReApply:
1) Invalid virtual machine configuration
2) File was not found. Storage policy change failure: The system cannot find the file specified.
Другие ошибки при миграции через Storage vMotion с изменение политики хранения:
1) A general system error occurred: PBM error occurred during PreMigrateCheckCallback: vmodl.fault.InvalidArgument;
Обновление VM HW до версии 13 не помогло.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
- Среднюю нагрузку в IOPs на дисках сервера за 5-10 минут (где меньше, туда пишем)
- Свободное место на дисках сервера (проверка, можно ли туда писать)
- Объем трафика от ширины канала за 1-3-5-10 минут (IOPs может быть мало, места много, но канал забит на 99%)
Эти параметры собираются в таблицу, скриптом.
Раз в несколько минут срабатывает анализатор, который на основании этих данных выставляет вес каждой ноды для заливки файлов.
А вот если надо балансировать данные между нодами, то тут надо считать нагрузку по чтению, загрузку канала, объем занимаемого места. И уже на основании этих данных выделять горячие ноды с SSD для часто запрашиваемых файлов, средние и холодные. И думать как сделать миграцию на Вашем продуктиве.
Обычно это по ночам, но все зависит от Вашего паттерна нагрузки на файлы.
Для фото объявлений, например, обычно характерна большая нагрузка в первые дня, потом можно перемещать в среднюю зону.