Взятие под контроль разрастания виртуальных машин (часть 3)

• Взятие под контроль разрастания виртуальных машин (часть 2)
• Взятие под контроль разрастания виртуальных машин (часть 6)
• Взятие под контроль разрастания виртуальных машин (часть 7)
• Взятие под контроль разрастания виртуальных машин (часть 8)
• Взятие под контроль разрастания виртуальных машин (часть 9)
• Взятие под контроль разрастания виртуальных машин (часть 10)
• Взятие под контроль разрастания виртуальных машин (часть 11)
• Взятие под контроль разрастания виртуальных машин (часть 12)
• Взятие под контроль разрастания виртуальных машин (часть 18)

В моей предыдущей статье я объяснил, что наиболее сложной частью сокращения разрастания виртуальных машин было выявление виртуальных машин, которые больше не используются. Как администратор, вы, вероятно, уже имеете относительно хорошее представление о том, какие виртуальные машины больше не используются. Однако самое сложное — доказать, что вы правы. В конце концов, вы не можете просто случайно удалить виртуальные машины, которые, по вашему мнению, не используются, потому что, если вы ошибетесь, удаление виртуальной машины повлечет за собой вполне реальные последствия.

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

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

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

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

Теперь давайте предположим, что из-за того, что виртуальная машина используется так редко, кто-то в ИТ-отделе ошибочно принял ее за заброшенную и отключил. Примерно через шестьдесят дней пребывания в автономном режиме ИТ-отдел предполагает, что виртуальная машина никому не нужна, поскольку никто не заметил, что она была отключена в течение последних двух месяцев. Виртуальная машина удалена, а IT занимается своими делами. Через несколько недель настало время выпуска квартального отчета. Именно тогда финансовый отдел замечает, что не может получить доступ к виртуальной машине. Они звонят в ИТ, и вы можете представить себе драму, которая разворачивается оттуда. Надеюсь, есть резервная копия виртуальной машины.

Я хочу сказать, что старый метод выключения виртуальной машины и ожидания, пока кто-нибудь сообщит о ее недоступности, в лучшем случае надежен, а в худшем — катастрофичен. Поэтому ИТ-отделу нужен гораздо лучший метод определения владельца виртуальной машины и ее назначения. Однако, как и многие другие вещи в ИТ, это гораздо легче сказать, чем сделать.

Итак, как вы можете идентифицировать виртуальные машины, которые могли или не могли быть заброшены? Это вопрос на миллион долларов. Мой ответ на этот вопрос может вас удивить. Мой ответ заключается в том, что это не то, что вы должны делать прямо сейчас. Позвольте мне объяснить себя.

Предположим на мгновение, что в организации подключено примерно 500 виртуальных машин. Вам, как администратору, было поручено убрать разрастание виртуальных машин. Вы почти уверены, что существует по крайней мере двадцать или тридцать виртуальных машин, которые были заброшены, но вы пока не знаете, какая именно. Заманчиво попытаться идентифицировать эти виртуальные машины сразу же, но это может быть огромной ошибкой.

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

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

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

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

Например, в один из предыдущих выпусков Microsoft System Center Microsoft включила замечательную функцию, которая позволяла вам устанавливать дату истечения срока действия виртуальной машины. Непосредственно перед истечением срока действия виртуальной машины владельцу может быть автоматически отправлено сообщение электронной почты, и у владельца будет возможность либо обновить виртуальную машину, либо продолжить и дождаться истечения срока ее действия. К сожалению, этой функции больше нет в текущей версии System Center. Вы по-прежнему можете добиться этой функциональности окольным путем, воспользовавшись преимуществами настраиваемых свойств и запуска книг в System Center Orchestrator. Идея состоит в том, что вы можете использовать настраиваемое свойство, чтобы установить дату истечения срока действия для каждой виртуальной машины, а затем создать книгу выполнения, которая проверяет каждый день, какие виртуальные машины скоро истечет, а затем предпринимает действия на основе этой даты истечения срока действия.

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

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

Вывод

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

• Взятие под контроль разрастания виртуальных машин (часть 2)
• Взятие под контроль разрастания виртуальных машин (часть 6)
• Взятие под контроль разрастания виртуальных машин (часть 7)
• Взятие под контроль разрастания виртуальных машин (часть 8)
• Взятие под контроль разрастания виртуальных машин (часть 9)
• Взятие под контроль разрастания виртуальных машин (часть 10)
• Взятие под контроль разрастания виртуальных машин (часть 11)
• Взятие под контроль разрастания виртуальных машин (часть 12)
• Взятие под контроль разрастания виртуальных машин (часть 18)