Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Microsoft Hyper-V Server 2008/2012/2016

Модерирует : lynx, Crash_Master, dg, emx, ShriEkeR

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Открыть новую тему     Написать ответ в эту тему

nikolaevsergey



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Microsoft Hyper-V.
Обсуждение бесплатного гипервизора, а также роль в сервере 2008/2012/2012R2.

Описание:
Виртуализация серверов позволяет взять одно физическое устройство и установить на нем (и использовать одновременно) две или более среды ОС, которые потенциально различны и имеют различные учетные данные, стеки приложений и так далее. Hyper-V – это технология виртуализации нового поколения, основанная на 64-битном гипервизоре, которая предлагает платформу с надежными и масштабируемыми возможностями. Вместе с System Center, она предлагает единый набор интегрированных средств управления для физических и виртуальных ресурсов.

Требования:
64-разрядный x86-процессор.
Поддержка аппаратной виртуализации Intel-VT или AMD-V
Поддержка технологии Data Execution Prevention.

Ссылки:
Домашняя страница (англ.)
Hyper-v 2008R2 free, обновления и службы интеграции linux (рус)
Статьи на TechNet первая и вторая (обе рус.)
Руководство по установке и развёртыванию (англ)
Родственная тема о Windows Server 2008
Русскоязычный ресурс о виртуализации и виртуальных машинах
Утилита проверки процессора
Спецификация процессоров Intel и AMD (десктоповые и серверные)

Роль Hyper-V можно поднять на любом Windows Server 2008/2008R2/2012/2012R2 (и даже Win8/8.1) 64bit. Hyper-V Server 2008/2008R2/2012/2012R2 как таковой бесплатен, требуется только лишь лицензия на каждую виртуальную машину.

Всего записей: 141 | Зарегистр. 25-10-2006 | Отправлено: 15:18 19-10-2008 | Исправлено: Paromshick, 11:52 18-05-2017
Paromshick



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Может добавить в название темы /2016 ?

А вот добавил

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 11:53 18-05-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
У меня вопрос, но не уверен, что по теме, т.к. часть вопроса по теме SQL.  
 
Недавно тут обсуждал возможности и варианты установки SQL+1C сервера под Hyper-V. основная причина, это доступность и быстрое восстановление.  
Много почитал про разных механизмов и мне заинтересовало failover cluster под hyper-V. только есть несколько архитектурных вопросов, на которые не могу найти ответа.  
У нас в офисе стоит w2k12 сервер, с относительно быстром интернетом, на на филиале win2016 , с медленным интернетом. порой у них бывают обрывы и тормоза с интернетом.  
Мы с ними работаем с одной базой. на данный момент они к нам подключаются по VPN и (пока что по терминалу) подключаются к 1С.
Вот общая схема:  
   
 
Если настроить между офисами кластер, то будет ли все нормально с репликацией? например у филиала интернет глючит, а в это время у нас в базе выписывают товар. Естественно, реплицироваться не будет база и менеджеры филиала увидят только старую информацию из локального кластера..
Хотя можно ли всех клиентов (и наших и филиал) подключить только к нашему(основному) серверу, и разрешить переключится к резерву, если первый сервер физически вышел из строя или принудительно переключаем на второй сервер временно, для замены/переустановки сервера в офисе?  

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 00:13 12-06-2017
d0r0fey



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack
возьми второй интернет, где другой магистральный провайдер в обоих точках и настрой роутер. У нас так сделано.
 
 
 
Добавлено:
если база одна, то она одна )),и продукция на складе одна, - что там резервировать? Тогда должно быть две базы, иначе будут проблемы при падении интернета.

Всего записей: 1364 | Зарегистр. 13-03-2009 | Отправлено: 01:43 12-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
d0r0fey
 
 

Цитата:
 возьми второй интернет, где другой магистральный провайдер в обоих точках и настрой роутер. У нас так сделано.  

Можно немного подробнее рассказать что как сделано у вас ?  
 

Цитата:
если база одна, то она одна )),и продукция на складе одна, - что там резервировать? Тогда должно быть две базы, иначе будут проблемы при падении интернета.

да, у нас база одна. у нас производственный цех, со всеми вытекающими программами (1с предприятие, зарплата+кадры, бухгалтерия)
Филиал с нашей базы выписывает товар на продажу. то есть мы тоже продаем, филиал тоже. Так вот, думал у них тоже поставить сервер резервный, чтоб при падении нашего все перешли туда.

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 11:02 12-06-2017
Paromshick



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack
Насколько я понял из темы, ссылку на которую вы привели и я в ней горячо учавствовал, вас не интересуют очевидные вещи, а подробное их разъяснение вы считаете "манией величия". На случай, если я ошибся:
Географически разносить ноды failover кластера - это нонсенс. Таким образом выстраивать failover (высокая надёжность, высокая доступность, еще такие термины встречаются) кластер распределяя ноды между офисам - выкиньте из головы. Почему? Задайте себе вопрос, а где будет находится БД? Если где-то в одном месте, то... Понимаете?
Допустим, вы разнесете ноды по разным офисам, но смотрят они у вас на одну базу. Тогда, помимо вопроса ЗАЧЕМ? ведь база у вас в одном месте, встает вопрос практический:
Клиенты должны смотреть на активную ноду. Обычно, это реализуется назначением кластеру одного IP адреса, который "мапится" активной ноде. Она и обслуживает клиентов. Представляете себе сложность реализации преключения нод? Активная выпадает, пассивная подхватывает IP (уже нереализуемо для географически распределенной системы с разными подсетями, но вдруг), а мужики-то и не знали (рекламный слоган. для туп.). Как мужики клиентские компьютеры, сетевое оборудование и т.д. узнают, что искомый IP находится совсем в другом месте? NLB? Масштаб решения - зашкаливает.
Выкиньте из головы.
То, что вы имеете в виду, это по-видимому, тот "кластер", что связан с репликацией машин. Два идентичных скуля (с двумя идентичными базами), которые реплицируются от активной к пассивной, с некой задержкой. Смотрите по задержкам репликации, но, должен сказать, что у HV они вас не порадуют ни разу.
Кластер NLB вас так же не устроит, расписывать не буду.
 
Вам вот что надо: реализовать кластер в одном месте, в котором имеется для него условия. Обеспечить клиентам доступ к нему, как лучам к центру звезды. Самое надежное - сдлеать терминальную ферму.
 
Таким образом, на вашем HV сервере вырисовываются:
Две ноды скуля, либо в классическом failover, либо always on, про последний ничего не знаю. Две ноды RDSH. Сервер 1С, который так же можно кластеризовать, у вендора есть подробный мануалы..
Вот такой аппетит. Потому, третью планку, вы всё-таки купите, не жидитесь.
Это будет называться DPC\ЦОД (Data Processing Center\Центр Обработки Информации).
Минус вашего решения - вы реализуете его на одной железке, и в случае ее подения... Сами понимаете.
Отсюда возникает вопрос, а зачем тогда вообще клатеризовать? SQL для защиты от програмных ошибок на одной ноде и безостановочной (на ту же профилактику) работы, RDSH для распределения нагрузки и безостановочной работы, сервер 1С - хз. Так что подождите пока с кластером.
Просто изучите вопрос и заложите масштабируемость. Зачем? Железа то нет! Будет. Когда перейдете на новое, то появится "старое".
Масштабируемость возможна только в случае использования внешего хранилища, а у вас его "типа нет". Да есть оно у вас. Есть.


----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 15:11 12-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Paromshick
 

Цитата:
Насколько я понял из темы, ссылку на которую вы привели и я в ней горячо учавствовал, вас не интересуют очевидные вещи, а подробное их разъяснение вы считаете "манией величия".

да, есть такое дело. это форум, а не ринг или дебаты, чтоб показать свое превосходство или залошить собеседника.  
А так, я всегда благодарен за адекватный и по теме ответ.  

Цитата:
Географически разносить ноды failover кластера - это нонсенс.

Это личное мнение, или технологические издержки? Если "отказа устойчивые кластеры" нельзя разместить в разных сегментах интернета, то вопрос закрыт на этом.  
 

Цитата:
Представляете себе сложность реализации преключения нод?

К сожалению не представляю, потому что никогда не пришлось настроить или обслуживать. все что знаю - это из всяких интернет статей.  

Цитата:
То, что вы имеете в виду, это по-видимому, тот "кластер", что связан с репликацией машин. Два идентичных скуля (с двумя идентичными базами), которые реплицируются от активной к пассивной, с некой задержкой. Смотрите по задержкам репликации, но, должен сказать, что у HV они вас не порадуют ни разу.
Кластер NLB вас так же не устроит, расписывать не буду.  

Смотрите что мне хотелось, возможно это не "отказоустойчивый кластер", а что то другое ))  
У нас стоит главный сервер, на котором крутится SQL2016+1C, все это хочу ставить под Hyper-V. К этому серверу подключены около 35 наших, локальных пользователей и 10 удаленных (с другого города).  
Сервер требует высокий аптайм, т.к. с ним работают почти круглосуточно. Недавно был инцидент, с вылетом RAID массива, может казаться фантастикой, но 2 диска RAID1 сгорели, из за замыкания USB разъема. Пока купили диски, восстановили все это, БД откатили, привели все в порядок, потеряли 2 дня целом. это был обычный системный блок. Сейчас взяли серверную платформу, но страх все же есть, хочется быть готовым к худшему.
По мне , кластер это иметь рабочий клон системы на другом железе, желательно в другом месте/сегменте сети/города, чтоб исключить все риски. Вот и думал в филиале поставить второй сервер, и чтоб наш сервер туда реплицировался. Если не дай бог накрылся наш сервер, на время всех переподключить на резервный сервер, пока будем наш ремонтировать.  
 

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 16:30 12-06-2017
Paromshick



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack

Цитата:
это форум, а не ринг или дебаты, чтоб показать свое превосходство или залошить собеседника.

Никто никого не лошил, но три раза объяснять очевидность... Можно было бы сказать, что обувайте свой болид в резину от трактора, но это именно форум. Кто-нибудь прочтет и подумает, что это норм.

Цитата:
Это личное мнение, или технологические издержки?

По-моему, популярно объяснено выше. Скажу еще раз: географически разносить ноды файловер кластера - это нонсенс.

Цитата:
К сожалению не представляю

Попробуйте объединить ваши офисы в одну подсеть. Подумайте, попредставляйте в эту сторону.

Цитата:
По мне , кластер это иметь рабочий клон системы на другом железе, желательно в другом месте/сегменте сети/города, чтоб исключить все риски.  

Именно так. Клонируется железо. На случай падения метеорита - клонируется целиком DPC
Иначе - бэкап. Просто бэкап. Поднять гдет-то вынь, накатить скуль и примапить базы, как временное решение, это дело не двух дней.
А вообще - по деньгам. Двойная отказоустойчивость - двойные деньги по железу и софту. Это всегда так. Но бэкапа отказоустойчивость не отменяет ни разу. Бэкап - форевер В другое здание
 
Я вам о том говорю, что можно в вашем случае, сделать грамотный planning и, когда ваше старое железо высвободится, а оно высвободится, сделат его второй нодой кластера. Если изначально не сделать заточенный под кластер дизайн, пусть и с одной нодой, то потом масштабировать... Впрочем, справитесь
 


----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 17:01 12-06-2017 | Исправлено: Paromshick, 17:03 12-06-2017
uncleShi



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Paromshick
Цитата:
По-моему, популярно объяснено выше. Скажу еще раз: географически разносить ноды файловер кластера - это нонсенс.
Не, ну чего уж так категорично, как верно замечено, всё от денег зависит. Две площадки(~10 км), между ними 6 выделенных SMF(по разным трассам). Стораджи+ноды+сервера управления стораджами+FC-коммутаторы+Eth-коммутаторы, пополам поделены между площадками. Никакого нонсенса.
 
+ софт для репликации между стораджам за дохрена денег...

Всего записей: 3018 | Зарегистр. 29-05-2003 | Отправлено: 17:18 12-06-2017 | Исправлено: uncleShi, 17:26 12-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
По-моему, популярно объяснено выше. Скажу еще раз: географически разносить ноды файловер кластера - это нонсенс.  

Я тоже еще раз говорю - это ваше мнение или общепринятые меры или стандарты?  
Вот например, есть много специалистов, которые тоже такого же мнения насчет SQL на Hyper-V, но это не значит, что это так.
 

Цитата:
Попробуйте объединить ваши офисы в одну подсеть. Подумайте, попредставляйте в эту сторону.  

 в смысле объединить? в каком плане? у нас между офисами уже есть VPN.  
 

Цитата:
Иначе - бэкап. Просто бэкап. Поднять гдет-то вынь, накатить скуль и примапить базы, как временное решение, это дело не двух дней.  

бекап будет, естественно, локально. Но с чего вы решили что SQL отдельно стоит? все на одном сервере у нас будет ))) MSSQL и 1С. База 1С будет хранится в SQL. он только для 1С. Конечно, MS рекомендует ставить по схеме: один сервис = один сервер, но у нас не такая колоссальная нагрузка, все на одном нормально справится.  

Цитата:
Я вам о том говорю, что можно в вашем случае, сделать грамотный planning и, когда ваше старое железо высвободится, а оно высвободится, сделат его второй нодой кластера. Если изначально не сделать заточенный под кластер дизайн, пусть и с одной нодой, то потом масштабировать...

да, согласен. по этому и спрашиваю тут все эти дела, чтоб заранее спроектировать архитектуру и потом не переделывать. Каждая переделка это остановка производства, соответственно потеря дохода.  
 

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 17:25 12-06-2017
uncleShi



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
del

Всего записей: 3018 | Зарегистр. 29-05-2003 | Отправлено: 17:26 12-06-2017 | Исправлено: uncleShi, 17:27 12-06-2017
Paromshick



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
uncleShi
Я просто в теме, человек на планке памяти экономит.
И далее, в описанном вами конфиге, проще разнести кластеры, а не ноды. Ноды можно, но это нонсенс. Нафиг? Когда можно рядом железку поставить. По всем показателям выигрышное решение.
 
contrafack

Цитата:
в смысле объединить? в каком плане?

Написано же. В одну подсеть. Затем посмотрте, как у вас ноды будут друг друга видеть, эмулировать отказ.

Цитата:
Но с чего вы решили что SQL  

Я ничего не решал, мне некогда сейчас и завтра тоже. Пишите, если что
Советую подумать в такой конфиг, для начала. Цимус в iSCSI хосте, у вас и сервер и хранилка all-in-one получатся и сможете добавлять ноды. По внутренней шине весь ваш iSCSI пойдет, у HV 10G виртуальный адаптер кУпите
 


----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 17:42 12-06-2017 | Исправлено: Paromshick, 11:23 13-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Paromshick
 
Мне кажется мы не понимаем друг друга. зачем мне в одной серверной ставить 2 сервера-кластера?  
у нас нет такой нагрузки, чтоб балансировать нагрузки.  
Я просто хочу построить такую инфраструктуру, чтоб при выхода из строя основного сервера, в очень короткое время можно было запустить новый (другой/резервный) сервер.  
Рядом не хочу ставить. безопасник "disaster plan" делает и там есть такие риски, как наводнение, пожар. У нас он в приоритете, так как находимся около водохранилища, и пожары тоже чаще стали у нас на промзоне.  
По этому в другом городе хочу поставить сервер, все равно планирую или купить VDS или облако и там хранить резервные копии. хотел бы хранить в филиале, но у них интернет слабый, каждый день не получится туда заливать бекапы.  
 

Цитата:
Я ничего не решал, мне некогда сейчас и завтра тоже. Пишите, если что
Советую подумать в такой конфиг, для начала. Цимус в iSCSI хосте, у вас и сервер и хранилка all-in-one получатся и сможете добавлять ноды. По внутренней шине весь ваш iSCSI пойдет, у HV 10G виртуальный адаптер кУпите

Эххх, понял бы еще что и как делать ))))))

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 18:45 12-06-2017
Paromshick



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack
Вчера думалось иначе, чем сегодня Это я про свободное время.

Цитата:
Я просто хочу построить такую инфраструктуру, чтоб при выхода из строя основного сервера, в очень короткое время можно было запустить новый (другой/резервный) сервер.  

Failover cluster предполагает, что при выходе из строя одной ноды (железо, ОСь сбойнула, вирус пожрал, админ наадминил - не важно) вторая включается автоматически и клиенты не замечают вообще ничего. Если у вас нет мониторинга и эвентов, то и вы ничего не замечаете Это ответ на ваш вопрос
Цитата:
зачем мне в одной серверной ставить 2 сервера-кластера?  
Это не два кластера, а две ноды, одна из которых совмещена с общим хранилище, которого у вас нет. Нету, ведь. А было бы
Если же следовать в строгом русле вашего ТЗ, то... писал вроде. Нет ничего проще, чем поднять такой же вынь с тем же IP, накатить скуль и примапить базы. Планируйте этот вариант тогда. Имидж системы - самое то. Sysprep'ом его обработать и... Это не сложно
..

Цитата:
у нас нет такой нагрузки, чтоб балансировать нагрузки.  

Failover не балансирует нагрузку. Пока одна нода работает - остальные курят бамбук. Мануально я их нагружал, но это выходит за рамки вопроса

Цитата:
такие риски, как наводнение, пожар.

Географически разнести ЦОДы, а бэкап вынести в сарай до которого бросить оптический паткорд метров 500

Цитата:
Эххх, понял бы еще что и как делать ))))))  

Обычно определяются с тем, что хотят, что могут позволить, а затем планируют КАК.
 
Раз моё knowhow не надо - я уберу картинку с предыдущего поста, нечего ей так пылиться

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 11:22 13-06-2017 | Исправлено: Paromshick, 11:27 13-06-2017
Newbie



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack

Цитата:
У нас стоит главный сервер, на котором крутится SQL2016+1C, все это хочу ставить под Hyper-V. К этому серверу подключены около 35 наших, локальных пользователей и 10 удаленных (с другого города).  Сервер требует высокий аптайм, т.к. с ним работают почти круглосуточно.  
По мне , кластер это иметь рабочий клон системы на другом железе, желательно в другом месте/сегменте сети/города, чтоб исключить все риски. Вот и думал в филиале поставить второй сервер, и чтоб наш сервер туда реплицировался. Если не дай бог накрылся наш сервер, на время всех переподключить на резервный сервер, пока будем наш ремонтировать.  

 
То что вы хотите - это энтерпрайз и дешевым он не будет. Применительно к 1С - смотрите решение от Софтпойнт http://www.softpoint.ru/archive/products_id28.php . Оно позволяет работать с базой 1С одновременно в голове и филиалах. Дорого. Второй вариант - Azure. SQL + Backup. Тоже дорогое удовольствие, но уже кастрофоустойчиво.  
 
 
Paromshick

Цитата:
Failover не балансирует нагрузку.

Золотые слова. Не все об этом помнят. Добавлю еще, что Failover не обеспечение непрерывной работы, а отработка отказов с восстановлением работоспособности сервиса.

----------
Omnia tempus habent et suis spatiis transeunt universa sub caelo...

Всего записей: 432 | Зарегистр. 11-11-2003 | Отправлено: 12:29 13-06-2017 | Исправлено: Newbie, 12:57 13-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Paromshick
 

Цитата:
Failover cluster предполагает, что при выходе из строя одной ноды (железо, ОСь сбойнула, вирус пожрал, админ наадминил - не важно) вторая включается автоматически и клиенты не замечают вообще ничего. Если у вас нет мониторинга и эвентов, то и вы ничего не замечаете Это ответ на ваш вопрос

на первый взгляд это вроде то, что мне надо.  

Цитата:
Это не два кластера, а две ноды, одна из которых совмещена с общим хранилище, которого у вас нет. Нету, ведь. А было бы

да, я ошибся с определениями. ноды назвал кластерами потом посмотрел еще видеопрезентации и немного стало ясно что к чему.  
получается кластер состоит минимум из 3х нодов.  2 сервера и 1 хранилище. сервера работают с хранилищем.  

Цитата:
Нет ничего проще, чем поднять такой же вынь с тем же IP, накатить скуль и примапить базы. Планируйте этот вариант тогда. Имидж системы - самое то. Sysprep'ом его обработать и... Это не сложно  

Вот бы знать как еще это делать )))) сложно представляю что надо делать.  
второй сервер можно поставить в другом здании/городе? пусть в случае ЧП не сразу все перешли на него, но и чтоб минимум сократить простой.  
 
Newbie

Цитата:
Применительно к 1С - смотрите решение от Софтпойнт. Оно позволяет работать с базой 1С одновременно в голове и филиалах. Дорого.

схема мне понравился. получается рабочая база будет в 2х местах, да? а сколько это дело стоит? на сайте не нашел цены.. и как это будет выглядеть? мы должны у себя какой то софт ставить?  

Цитата:
Второй вариант - Azure. SQL + Backup. Тоже дорогое удовольствие, но уже кастрофоустойчиво.  

катастрофоустойчиво это хорошо, но руководство старой закалки и желает свои базы у себя держать. боится, что пойдет утечка клинической базы.  

Цитата:
Failover не обеспечение непрерывной работы, а отработка отказов с восстановлением работоспособности сервиса.
 

Мне час простой в полне приемлем. но больше - уже напряжно.  

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 22:26 13-06-2017
Newbie



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack

Цитата:
получается кластер состоит минимум из 3х нодов.  2 сервера и 1 хранилище. сервера работают с хранилищем.

Минимум - 2 ноды, желательно с одинаковым железом и однотипным производителем процессора, дисковое хранилище нарезается через storage spaces из дисков с SAS подключениями.  
 

Цитата:
Failover cluster предполагает, что при выходе из строя одной ноды (железо, ОСь сбойнула, вирус пожрал, админ наадминил - не важно) вторая включается автоматически и клиенты не замечают вообще ничего. Если у вас нет мониторинга и эвентов, то и вы ничего не замечаете

Неверно. Замечаете и еще как. При какой-то физической проблеме с узлом/нодой вся рабочая нагрузка перезапускается на другом узле/ноде. Перезапускается - это значит холодный старт операционной системы виртуального сервера. Незаконченные транзакции, несброшеный кэш - это норма риска. А географически распределенные узлы кластера требуют хорошего канала в интернет. А размещать рядом 2 узла вы не хотите. А если рассматривать решение не географически разнесенных узлов, то кластер совсем не обязателен - Hyper-V можно настроить на репликацию виртуальной машины. ВМ постоянно передает изменения на второй сервер виртуализации с интервалом 1-5 минут и при возникновении проблем с мастер-сервером запускает сервер-копию. Естественно рекомендуется ehternet 10-40 Gb на каждом сервере, и нарезка виртуальных дисков поменьше.  
 
По решению Софтпойнт - да. Рабочая база в 2 местах. На серверах работает агент по репликации данных. Проблем с блокировками нет. По цене - обращайтесь в Софтпойнт. У нас это решение уже пару лет 24х7 работает.  
 

Цитата:
руководство старой закалки и желает свои базы у себя держать. боится, что пойдет утечка клинической базы.

Ну иногда наши органы могут доставить проблем больше чем утечка базы, да и исходя из личного опыта, база утекает независимо от ее физического расположения.

----------
Omnia tempus habent et suis spatiis transeunt universa sub caelo...

Всего записей: 432 | Зарегистр. 11-11-2003 | Отправлено: 08:55 14-06-2017 | Исправлено: Newbie, 08:55 14-06-2017
Paromshick



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Тема ушла в офтоп, а потому я чуть пошучу и закончу
 
contrafack

Цитата:
сложно представляю что надо делать.

Ну, вы как бы начните. Сейчас сервис у вас в работе, и ОК. Приехало новое железо - начинайте с ним работать.
Или вы хотите по этапам? Вот в понедельник вы качаете и готовите дистрибутивы. Во вторник занимаетесь железом, осматриваете, при необходимости шьете, пробуете инсталить. В среду - время поработать - инсталите всё, что только можно инсталить (когда эта ерунда со средой закончится? (С)). В четверг, конфигурируете и настраиваете всё, что настраивается. В пятницу... Пятница - день бэкапов.
Знаете, когда я делал "готовое решение", то у меня было все описано в документе формата pdf для всех. Для сборщиков - какого цвета патчкорд куда втыкается, для цисковика - ТЗ по настройке циски, для админа, что как и с какими параметрами ставить...
Это стоило времени, само написание, и стоило денег МС сейчас идет к тому, что все это ппишется в километровом скрипте на powershell...
Вам же помогают посильно всем форумом. Вы начните, а оно пойдет. Пока сервис в продакшн не сдадите всегда сможете сделать любимый формат Цэ
 
Newbie
Раз вы отвечаете на мою цитату, то предположу, что отвечаете мне.

Цитата:
Перезапускается - это значит холодный старт операционной системы виртуального сервера. Незаконченные транзакции, несброшеный кэш - это норма риска.

Вот несогласный я. В SQL горячо запущенный движок подхватывает диски, базы и цепляя IP начинает отзываться так, как будто ничего не произошло. Даже реконнекта нет. Небольшая "задержка в сети" для клиента и всё. Конечно, если в момент сбоя шла транзакция, то она не завершается, НО повторяется. Механизм защиты транзакции от сбоя - в дизайне самой транзакции. Которая считается НЕ завершенной, пока НЕ произведена последняя запись на диск (по ссылке я коротко об этом обмолвился (последнее предложение первого абзаца), но меня не поняли). А диск - не сбоил.
Таким образом, мы приходим к тому, а что всё-таки называть failover (не NLB)кластером? Ведь можно

  • Поставить две ноды в кластер средствами "железа", то есть гипервизора. У всех такая возможность есть. Холодная нода - теневая копия "горячей" с задержкой на репликацию. Тогда, в общем случае, нет необходимости в общем хранилище вовсе. Так же, "холодная нода" не занимает пространство в RAM. Ноды можно располагать в разных концах планеты. Старт холодной ноды процесс инерционный, имеются "противопоказания", вопрос о перенацеливании клиентов - вопрос индивидуальный. В случае нахождения нод в одной подсети и даже VLANе, им можно пренебречь.
  • Поставить две ноды в кластер средствами ОС. Две постоянно работающие машины. Обе (каждая) занимают пространство в RAM и требуется диск кворума - общий ресурс. Говорят, что сейчас можно без него. Не пробовал и не хочу, ибо просто две работающие машины сами по себе - не интересны. Интересен сервис(ы), который(е) они обслуживают, а у них, как правило, есть некая "общая база". Но, указанный вариант может быть интересен для кластеризации сервисов, такой базы не имеющих, либо имеющих, но нечто "квази". Файл конфига например, который копируется раз в год вручную.
  • Поставить в кластер две ноды средствами приложения, как пример - описанное выше поведение MS SQL. Этот вариант наиболее распространён (в моей практике), но, как правило, требует использования в своем дизайне и второго варианта, но главное - общего хранилища. Здесь - можно делать ваще_всё.
  • Какой-то дикий микс, когда это оправдано или "душа просит". Не рассматриваю. Штучный дизайн.

Вот такой оффтоп.
 
Есть тема по кластерам? Да и есть ли что обсуждать?
 
Добавлено:

Цитата:
Есть тема по кластерам?

Вагон. И маленькая тележка
Оказывается, я в одной даже поучаствовал. Человек попытался географически разнести ноды кластера, выстраиваемого по второму варианту. Что-то у него случилось, кто бы мог предположить
Не надо так делать. Помимо общей бессмысленности, еще и сбойное решение, то есть не fail over, но fail forever получается.
Зачем?
 
Добавлено:

Цитата:
Минимум - 2 ноды

Я не тормоз, я медленный газ, это про меня
Начать можно с одной ноды, потом добавлять. Отказоустойчивость возникает при числе нод не менее двух. Масштабируемость системы возникает сразу.
Масштабируемость, гибкость, прозрачность. Отсюда растёт всё остальное, отказоустойчивость, надежность, совместимость и... ИМХО, вообще всё. Если говорить про Систему. Именно Систему.

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 10:08 14-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Paromshick
 
да, начал уже  
на соседнем топике написал:

Цитата:
Сегодня установил уже Hyper-V, и под него создал виртуальную машину. процессору выделил 6 ядер (из 12), ОЗУ - 16ГБ (из 32), статический HDD на 250ГБ (из 480ГБ, SSD диски, в RAID1)
Установил Windows 2012 standard, в свободном полете сжирает около 20% CPU и 23% RAM.  
Ну это все без SQL. завтра понаблюдаю после установки всех обновлений. если будет также, наверно надо будет увеличить и процессоры и ОЗУ.  
А вот с диском не знаю как быть.. один диск(VHDX) на 250GB хватит? или расширить? У нас получается такая тема:  
2 SSD по 250GB, в RAID1, сейчас там стоит хостовая система.  
2 SSD по 480GB в RAID1, на нем стоит гостевая система, с фиксированным виртуальным диском на 250gb.  

Сегодня поднял ресурсы: CPU поставил 8 ядер, RAM - 24GB.  
Теперь на холостом ходу 0-1% ЦП грузит и 12% ОЗУ.  
Надеюсь хватит ))  
Но вопрос дисков все еще открыт.

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 19:00 14-06-2017
Newbie



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
contrafack
Я бы отделил lun системы от lun данных SQL и lun tempdb - быстрее делать контрольные точки\снэпшоты не затрагивая том с данными.  


----------
Omnia tempus habent et suis spatiis transeunt universa sub caelo...

Всего записей: 432 | Зарегистр. 11-11-2003 | Отправлено: 12:08 15-06-2017
contrafack

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Newbie

Цитата:
Я бы отделил lun системы от lun данных SQL и lun tempdb - быстрее делать контрольные точки\снэпшоты не затрагивая том с данными.  

 
А это как делать? создать 3 VHDX или как ? не вкурсе просто этих дел

Всего записей: 3309 | Зарегистр. 21-04-2008 | Отправлено: 13:50 15-06-2017
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Microsoft Hyper-V Server 2008/2012/2016


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru