Серверы и сами неплохо умеют выключаться при перегреве.
Что до «не успеешь» — это гипербола. Ну или в Вашем ЦОДе домны работают.
У нас недавно отключились все чиллеры — человечески фактор.
Расчётные 45 минут ЦОД отстоял без активного охлаждения и без единого сбоя и выключать ничего не пришлось.
HPEшные, например, серверы в определённых конфигурациях просто не будут запускаться, если снять часть вентиляторов.
Может и у других вендоров так, не берусь утверждать. Как с этим думаете справляться?
В современном мире шпиндели никуда не делись и ещё долго не денутся.
Что до ваших ссылок — там точно так же сказано, что сначала будет снапшот ВМ выполнен.
Ну не то чтобы «совсем ничего» Да и развивают свой продукт в Veeam впечатляющими темпами.
Но когда в банке процент виртуализации немалый, легаси системы хоть и есть, но не доминируют числом, а выбор делают в пользу Commvault, лишая виртуализацию шикарной СРК с фичами, которые Commvault'у недоступны под лозунгом «Единая СРК! Единая СРК!» — это боль не совсем разумно, на мой непросвящённый взгляд.
все планируемые тормоза лишь заключаются в сбросе кэша базовода на диски и фиксации состояния
Угу, если на СХД CoW-механизм создания снапшотов — то это, конечно, никак не влияет на продуктив, которых на тех же шпинделях вертится. Понятно, что не смертельно, но с другой стороны вендоры СХД, особенно с CoW, и кол-во одновременных снапшотов лимитируют, а для высоконагруженных томов и вовсе не советуют их использовать. Тут где-то есть статья авторства KorP, можно поискать и почитать, интересно.
фиксируя состояние виртуальной машины тем что заставляет сбросить кэши на диск, а дальше
Дальше делается снапшот ВМ средствами гипервизора и только после этого — снапшот средствами СХД.
Ну хотя может это только у Veeam так, а я не в курсе.
Всегда меня коробило то, что в галактике DataLine всё называется инцидентом. Ну это помимо того, что сотрудники DC на запрос «демонтировать адаптеры из серверов» могут просто их вынуть из стойки — реальный случай в моей практике ))
Но работу автор с коллегами проделал, несомненно, огромную.
Хех, с решением схожей проблемы как-то просил коллега помочь.
При наличии свободных ресурсов в кластере FLR appliance отказывался запускаться.
Оказалось Admission Control насчитал, что ресурсов для failover'а не хватает, отключили его на время восстановления — всё получилось.
Как не первый год клиент Veeam могу подтвердить — отличная у вас L1, как и вся ТП, не перестаю качеством их работы восхищаться.
Глянул ради интереса статистику по своим кейсам: с марта 2014 было 13 кейсов, всего 1 кейс был передан на L2.
женщина не может быть инженером и с ним говорит, ну в самом лучшем случае секретарша
Кстати, решением нашего кейса на L2 занималась, если память не изменяет, Татьяна Королёва — тот момент, когда во время webex-сессия я себя секретаршей чувствовал, глядя как технично и профессионально она работает :)
Я ничего не сравниваю — просто показал на живом примере, какого коэффициента дедупликации удаётся достичь на работающих ВМ, лежащих на NetApp'е.
На Altavault, как и нам любом современном DD, полагаю, будут больше значения — там оффлайновые данные, которые сам девайс порубит на удобные ему блоки.
По поводу НетАпп-а тоже было бы интересно посмотреть сравнение — очень они хвалят свою дедупликацию.
Не бекап - работающие виртуальные машины на All-Flash'е NetApp'овском. Но для примера пойдёт, думаю.
Datastore Cluster : *****_AFF
Capacity (GB) : 4802
Used Space (GB) : 27816,58
Provisioned Space (GB) : 28130,67
Provisioned / Capacity ratio : 5,85
Storage Overcommit (%) : 585,81
По поводу НетАпп-а тоже было бы интересно посмотреть сравнение — очень они хвалят свою дедупликацию.
Не бекап — работающие виртуальные машины на All-Flash'е NetApp'овском. Но для примера пойдёт, думаю. Datastore Cluster : *****_AFF
Capacity (GB) : 9600
Used Space (GB) : 27816,58
Provisioned Space (GB) : 28130,67
Provisioned / Capacity ratio : 2,93
Storage Overcommit (%) : 193,03
Или не особо большой парк, но зато разбросан географически и не на всех площадках есть свои руки — туда инженера HPE на замену не оригинального диска не отправишь.
Что до «не успеешь» — это гипербола. Ну или в Вашем ЦОДе домны работают.
У нас недавно отключились все чиллеры — человечески фактор.
Расчётные 45 минут ЦОД отстоял без активного охлаждения и без единого сбоя и выключать ничего не пришлось.
Может и у других вендоров так, не берусь утверждать. Как с этим думаете справляться?
Что до ваших ссылок — там точно так же сказано, что сначала будет снапшот ВМ выполнен.
Но когда в банке процент виртуализации немалый, легаси системы хоть и есть, но не доминируют числом, а выбор делают в пользу Commvault, лишая виртуализацию шикарной СРК с фичами, которые Commvault'у недоступны под лозунгом «Единая СРК! Единая СРК!» — это
больне совсем разумно, на мой непросвящённый взгляд.Угу, если на СХД CoW-механизм создания снапшотов — то это, конечно, никак не влияет на продуктив, которых на тех же шпинделях вертится. Понятно, что не смертельно, но с другой стороны вендоры СХД, особенно с CoW, и кол-во одновременных снапшотов лимитируют, а для высоконагруженных томов и вовсе не советуют их использовать. Тут где-то есть статья авторства KorP, можно поискать и почитать, интересно.
Дальше делается снапшот ВМ средствами гипервизора и только после этого — снапшот средствами СХД.
Ну хотя может это только у Veeam так, а я не в курсе.
Но работу автор с коллегами проделал, несомненно, огромную.
во-во, я тоже хотел спросить: если уж два HA-кластера — это кровавый энтерпрайз, то у меня тогда что ))
:)
Не нужно.
Если уж совсем срочно — Veeam Extract Utility.
При наличии свободных ресурсов в кластере FLR appliance отказывался запускаться.
Оказалось Admission Control насчитал, что ресурсов для failover'а не хватает, отключили его на время восстановления — всё получилось.
Глянул ради интереса статистику по своим кейсам: с марта 2014 было 13 кейсов, всего 1 кейс был передан на L2.
Кстати, решением нашего кейса на L2 занималась, если память не изменяет, Татьяна Королёва — тот момент, когда во время webex-сессия я себя секретаршей чувствовал, глядя как технично и профессионально она работает :)
На Altavault, как и нам любом современном DD, полагаю, будут больше значения — там оффлайновые данные, которые сам девайс порубит на удобные ему блоки.
Вот правильные цифры:
Не бекап - работающие виртуальные машины на All-Flash'е NetApp'овском. Но для примера пойдёт, думаю.
Datastore Cluster : *****_AFF
Capacity (GB) : 4802
Used Space (GB) : 27816,58
Provisioned Space (GB) : 28130,67
Provisioned / Capacity ratio : 5,85
Storage Overcommit (%) : 585,81
Не бекап — работающие виртуальные машины на All-Flash'е NetApp'овском. Но для примера пойдёт, думаю.
Datastore Cluster : *****_AFF
Capacity (GB) : 9600
Used Space (GB) : 27816,58
Provisioned Space (GB) : 28130,67
Provisioned / Capacity ratio : 2,93
Storage Overcommit (%) : 193,03
Настройки Compession Level и Storage Optimization в тестовых заданиях у вас остались по умолчанию?