none
Количество общих томов кластера для VM. RRS feed

  • Вопрос

  • Добрый день Уважаемые коллеги!

    На данный момент собираемся конфигурировать двух узловой отказоустойчивый кластер на платформе WS 2012 R2. для организации кластерного стораджа нам выделяется почти 3 терабайта.

    Вопрос:

    Имеет ли смысл поделить данный сторадж на несколько стораджей, то есть ClusterStorage\Volume1,ClusterStorage\Volume2,ClusterStorage\Volume3 - допустим каждый по 1 терабайту ?

    Может все 3 терабайта отдать под кластерный сторадж,  это не играет особой роли ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 23 мая 2014 г. 8:14

Ответы

  • Вообще, есть рекомендации по разделению общих томов с точки зрения гостевых служб. Т

    Таким образом, ClusterStorage\System служит для хранениях системных дисков ВМ, ClusterStorage\Data для размещения данных приложений и служб, ClusterStorage\Logs — для логов Exchange и SQL, например.

    • Предложено в качестве ответа EugeneLeitanMVP 24 мая 2014 г. 19:39
    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:26
    Отвечающий
  • если шпиндели общие, то есть один массив, то нарезать на LUN смысла мало - быстродействие не улучшите, а гибкость в распределении пространства потеряете. если есть возможность разнести на разные шпиндели создав разные массивы, то лучше сделать как предлагает Денис, только размеры подкорректируйте - системным дискам надо совсем мало, а вот данным наоборот

    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:26
  • И своё оставлю .

    Не фанат менять структуру CSV (при условии, что диски одинаковые).  Встречал конфигурации Volume 1 = gold , Volume 2 = silver, Volume 3 = bronze. Как "априори" наименованием классификаций  VMM для разных лунов различной производительности. Но..

    При наличии одного большого луна: оставлять As is + при необходимости менять наименования внутри C:\ClusterStorage. Но это для административных целей и не более.

    Включение кеша для CSV на уровне кластера - по умолчанию (для меня). 

    #всегда (SharedVolumeBlockCacheSizeInMB для 2012)

    (Get-Cluster).BlockCacheSize = 512

    #оставляю по умолчанию в 2012(CsvEnableBlockCache). 2012 R2 (EnableBlockCache) - по умолчанию включено

    Get-ClusterSharedVolume "disk" | Set-ClusterParameter CsvEnableBlockCache/EnableBlockCache 1

    Все сказанное выше и чуть более Вы можете найти тут : http://technet.microsoft.com/en-us/library/jj612868.aspx

    To make the best use of CSV to provide storage for clustered virtual machines, it is helpful to review how you would arrange the LUNs (disks) when you configure physical servers. When you configure the corresponding virtual machines, try to arrange the VHD files in a similar way.

    Consider a physical server for which you would organize the disks and files as follows:

    • System files, including a page file, on one physical disk
    • Data files on another physical disk

    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    • Предложено в качестве ответа R.LevchenkoMVP 25 мая 2014 г. 5:21
    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:26
  • Всегда путаюсь с этим AlwaysOn Sql,если честно). Насколько знаю, на текущих FCI и делается AlwaysON Availability Groups и группу можно расширять путем добавления новых нод в виде вторичных реплик. количество ограничено,насколько помню.

    http://msdn.microsoft.com/en-us/library/ff929171.aspx#SQLServerFC

    А MPIO - это то, что делается в первую очередь. Без него,кстати, и тесты не пройдете = поддержки от МС не будет.


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:27
  • 1. Возможно неприменимо к Вам, но при рассмотрении перехода куда-то и на что-то,как правило, делают пилотное внедрение (тестовое развертывание, сбор и анализ производительности в течение 2 недель, к примеру) и смотрят на его результаты. Будет лучшим доказательством Вашему начальству.

    2. При переносе SQL в вирт.среду нужно сначала снять параметры производительности с Ваших текущих серверов, а потом их учитывать при конфигурации ВМ. Виртуализировать сейчас нужно и можно практически всё без потери производительности на глобальном уровне. Довольно часто проблемы не в SQL или конфигурации ВМ , а в "коде" БД, по причине которых возникают блокировки очереди запросов (наблюдал в 1С, к примеру). Личные рекомендации: фиксированные vhd, раздельные диски под ОС, логи, данные, динамическая память в конфигурации min=max (даст возможность горячего изменения памяти, но работать подобно статике) или просто статику, net/storage qos для других ВМ на хосте. 

    3.Если 1) действительно высоконагруженная система 2) 2 сервера будут чисто под ВМ SQL , то можете на физике оставлять. Минусы в административном плане, а начальник рад будет)


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:27

Все ответы

  • Вообще, есть рекомендации по разделению общих томов с точки зрения гостевых служб. Т

    Таким образом, ClusterStorage\System служит для хранениях системных дисков ВМ, ClusterStorage\Data для размещения данных приложений и служб, ClusterStorage\Logs — для логов Exchange и SQL, например.

    • Предложено в качестве ответа EugeneLeitanMVP 24 мая 2014 г. 19:39
    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:26
    Отвечающий
  • Добрый день!

    Диски одинаковые?


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

  • Добрый день!

    Диски одинаковые?


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    Да ,это одно и то же СХД.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

  • если шпиндели общие, то есть один массив, то нарезать на LUN смысла мало - быстродействие не улучшите, а гибкость в распределении пространства потеряете. если есть возможность разнести на разные шпиндели создав разные массивы, то лучше сделать как предлагает Денис, только размеры подкорректируйте - системным дискам надо совсем мало, а вот данным наоборот

    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:26
  • И своё оставлю .

    Не фанат менять структуру CSV (при условии, что диски одинаковые).  Встречал конфигурации Volume 1 = gold , Volume 2 = silver, Volume 3 = bronze. Как "априори" наименованием классификаций  VMM для разных лунов различной производительности. Но..

    При наличии одного большого луна: оставлять As is + при необходимости менять наименования внутри C:\ClusterStorage. Но это для административных целей и не более.

    Включение кеша для CSV на уровне кластера - по умолчанию (для меня). 

    #всегда (SharedVolumeBlockCacheSizeInMB для 2012)

    (Get-Cluster).BlockCacheSize = 512

    #оставляю по умолчанию в 2012(CsvEnableBlockCache). 2012 R2 (EnableBlockCache) - по умолчанию включено

    Get-ClusterSharedVolume "disk" | Set-ClusterParameter CsvEnableBlockCache/EnableBlockCache 1

    Все сказанное выше и чуть более Вы можете найти тут : http://technet.microsoft.com/en-us/library/jj612868.aspx

    To make the best use of CSV to provide storage for clustered virtual machines, it is helpful to review how you would arrange the LUNs (disks) when you configure physical servers. When you configure the corresponding virtual machines, try to arrange the VHD files in a similar way.

    Consider a physical server for which you would organize the disks and files as follows:

    • System files, including a page file, on one physical disk
    • Data files on another physical disk

    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    • Предложено в качестве ответа R.LevchenkoMVP 25 мая 2014 г. 5:21
    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:26
  • Да спасибо господа, у нас так и получается все 3 терабайта с одного хранилища, то есть разбиение допустим никак не влияет на отказоустойчивость и соответственно если падает хранилище-падает и CSV.Но в данный момент мужики делают MultiPath на всякий пожарный.)).А папочки на clusterstorage, для удобства размещения и поняности-это скорее административная цель, как и сказал Роман )

    Коли уж зашел разговор о стораджах, то хотелось бы полюбопытствовать вашим мнением.Есть лицензии на SQL 2014 - там есть такая технология, что для баз можно использовать не LUN презентованный из SAN-как раньше,а  так же разместить базу на CSV и соответственно реализовать обычный SQL кластер но с поддержкой CSV.

    Имеем WSFC кластер и SQL SERVER 2014 FCI, который размещает БД-ых на CSV- томе.
    Вопрос: Можно ли SQL SERVER 2014 FCI объединить в Always On с SQL SERVER 2014 StandAlone, который развернут на третей ноде кластера ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!







    • Изменено rеstless 23 мая 2014 г. 17:55
  • Всегда путаюсь с этим AlwaysOn Sql,если честно). Насколько знаю, на текущих FCI и делается AlwaysON Availability Groups и группу можно расширять путем добавления новых нод в виде вторичных реплик. количество ограничено,насколько помню.

    http://msdn.microsoft.com/en-us/library/ff929171.aspx#SQLServerFC

    А MPIO - это то, что делается в первую очередь. Без него,кстати, и тесты не пройдете = поддержки от МС не будет.


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:27
  • Всегда путаюсь с этим AlwaysOn Sql,если честно). Насколько знаю, на текущих FCI и делается AlwaysON Availability Groups и группу можно расширять путем добавления новых нод в виде вторичных реплик. количество ограничено,насколько помню.

    http://msdn.microsoft.com/en-us/library/ff929171.aspx#SQLServerFC

    А MPIO - это то, что делается в первую очередь. Без него,кстати, и тесты не пройдете = поддержки от МС не будет.


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    Роман спасибо! Ну и последний вопрос.

    У нас есть некая высоконагруженная система на сервере PrimeQuest с поддержкой Itanium, все это используется на SQL 2005 и в физике. Сейчас у нас под это дело куплено два новеньких HP DL 580 E.Но встал вопрос-Наш начальник уверяет, что переносить систему на новые серваки надо полностью так же на физику, что дескать виртуализация SQL будет сильно нагружать систему.Вот на фоне того что есть и SQL 2014 и можно использовать совместно и CSV и OlwaysON, подскажите-может быть все таки стоит виртуализировать данные нагрузки ? Как обосновать, может есть статья определенная-сравнение за и против виртуализации SQL?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 24 мая 2014 г. 12:38
  • 1. Возможно неприменимо к Вам, но при рассмотрении перехода куда-то и на что-то,как правило, делают пилотное внедрение (тестовое развертывание, сбор и анализ производительности в течение 2 недель, к примеру) и смотрят на его результаты. Будет лучшим доказательством Вашему начальству.

    2. При переносе SQL в вирт.среду нужно сначала снять параметры производительности с Ваших текущих серверов, а потом их учитывать при конфигурации ВМ. Виртуализировать сейчас нужно и можно практически всё без потери производительности на глобальном уровне. Довольно часто проблемы не в SQL или конфигурации ВМ , а в "коде" БД, по причине которых возникают блокировки очереди запросов (наблюдал в 1С, к примеру). Личные рекомендации: фиксированные vhd, раздельные диски под ОС, логи, данные, динамическая память в конфигурации min=max (даст возможность горячего изменения памяти, но работать подобно статике) или просто статику, net/storage qos для других ВМ на хосте. 

    3.Если 1) действительно высоконагруженная система 2) 2 сервера будут чисто под ВМ SQL , то можете на физике оставлять. Минусы в административном плане, а начальник рад будет)


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    • Помечено в качестве ответа rеstless 26 мая 2014 г. 6:27
  • Всем большое спасибо!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!