Назад | Перейти на главную страницу

Плохая идея - совмещать ИТ-инфраструктуру и виртуальные машины разработки на одной физической машине?

Не могли бы вы, как системный разработчик, поместить виртуальные машины, отвечающие за базовую инфраструктуру (dns / dhcp / directory / web / wiki / repos / file share и т. Д.), И виртуальные машины, используемые для разработки и тестирования, на одной физической машине?

Мое мнение:

Для

Против

Обычно я бы сказал не делать этого. Мы рассматриваем разработку как область, которая может и будет ломаться из-за характера работы (бесконечные циклы, плохо оптимизированные операторы SQL и все эти забавные вещи)

Я вообще отношусь к средам разработки как к тестовым средам для операционных / сетевых отделов. Хотя это может не сработать для вас, если вам нужно время работы 5 9 в вашей среде разработки.

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

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

Еще одна вещь, на которую следует обратить внимание, - это конфликт на диске, вызванный неконтролируемым процессом записи или чтения с диска.

Чтобы поговорить с вашими «Против»:

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

  2. С такими опциями, как VMware DRS или Пулы ресурсов, вы можете легко минимизировать риск выхода виртуальной машины из-под контроля.

В небольшом магазине я бы сделал это.

Я бы, вероятно, попытался настроить все так, чтобы виртуальные машины разработки находились в отдельной vm-сети с отдельным физическим адаптером и VLAN, и привязать виртуальные машины разработки к определенным процессорам, чтобы снизить вероятность того, что вы слишком сильно повлияете на виртуальную машину с основной службой.

Кроме того, если дела пойдут плохо, вы всегда можете переместить виртуальные машины на другой сервер, верно?

Я могу придумать один сценарий, в котором вы, вероятно, захотите иметь отдельную среду для тестирования, в частности.

Допустим, вы хотите протестировать новую версию гипервизора или виртуальных инструментов, которые вы используете для запуска и управления виртуальной средой. Вы бы не хотели делать это в своей производственной среде.

Вам следует всегда отдельные среды производства и разработки / контроля качества

Мы делали это раньше без проблем.

Если вы используете Hyper-V и хотите, чтобы разработчики могли управлять своим собственным набором виртуальных машин, вам стоит попробовать Диспетчер авторизации. Это позволит вам предоставить им доступ только к определенным виртуальным машинам и определенным операциям для этих виртуальных машин.