☰

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

tag-icon • tag-icon virtualization capacity-planning
Является ли смешивание ИТ-инфраструктуры и виртуальных машин разработки на одной физической машине плохой идеей?

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

Мое мнение:

Для

  • более эффективное использование оборудования — большинство ИТ-ВМ имеют относительно низкую нагрузку
  • возможность тратить больше на лучшее оборудование/получать деньги из других проектов
  • меньше общих расходов

Против

  • У ИТ и разработки, вероятно, в любом случае разные (отдельные) бюджеты.
  • Неконтролируемая разработка виртуальных машин может оказать неблагоприятное воздействие на основные ИТ-сервисы

решение1

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

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

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

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

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

решение2

Чтобы обсудить ваши пункты «Против»:

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

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

решение3

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

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

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

решение4

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

Связанный контент