Избегайте этих «подводных камней» виртуальных машин Azure

Переход в облако должен быть легким, верно? Я имею в виду, насколько сложно будет развернуть или перенести рабочие нагрузки вашего сервера на виртуальные машины, работающие в Microsoft Azure? Ну, это не всегда так просто, как кажется. Есть вещи, на которые нужно обращать внимание при создании облачной инфраструктуры с использованием виртуальных машин Azure. Есть вещи, которые могут противоречить интуиции, вещи, которые вы можете легко сделать неправильно, если не будете осторожны. Другими словами, есть некоторые «подводные камни», о которых вам нужно знать, прежде чем вы начнете, чтобы вы могли избавить себя от головной боли в будущем.

Чтобы помочь нам понять некоторые подводные камни, с которыми вы можете столкнуться при использовании виртуальных машин Azure, я попросил Шэрон Беннетт поделиться с нами некоторыми мыслями по этому поводу. Шэрон работает инструктором по информационным технологиям в LinkedIn Learning, где создает учебные материалы, посвященные Microsoft Office 365 и Microsoft Azure (вы можете ознакомиться с ее курсами в LinkedIn). Ранее Шэрон работала с партнерами Microsoft, предоставляя технические советы и рекомендации по развитию бизнеса, чтобы помочь облачных предложений.Шарон является сертифицированным архитектором облачных решений Microsoft, сертифицированным тренером Microsoft и имеет несколько других сертификатов Microsoft.Кроме того, Шарон также преподавала Azure и другие технологии Microsoft партнерам Microsoft.Шарон обладает более чем 20-летним техническим опытом и собственным уроки предпринимательства для ее положения. Вы можете связаться с Шэрон через LinkedIn или последовать за ней в Твиттере на @bennettbusiness. Давайте передадим слово Шэрон.

Что может быть проще?

На протяжении многих лет я сталкивался с теми же трудностями, что и у новых администраторов Azure, когда дело доходит до виртуальных машин Azure. Как ИТ-специалисты, мы все обожаем виртуальные машины Azure! Мы можем раскрутить виртуальную машину за семь минут (и чуть дольше для SQL); мы можем удалить их, когда закончим с ними, и лицензирование включено при использовании одного из шаблонов Azure. Что может быть проще? И, возможно, в этом и есть корень проблемы: это просто. У нас возникают проблемы, потому что мы просто раскручиваем виртуальную машину и начинаем с ней работать, не принимая во внимание передовой опыт и то, что я люблю называть «подводными камнями». Ниже приведены некоторые из наиболее распространенных, с которыми я сталкивался.

1. Отсутствие защиты виртуальных машин Azure

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

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

2. Предполагая, что ваша виртуальная машина всегда будет доступна.

Одно из самых больших преимуществ виртуальных машин заключается в том, что вам не нужно беспокоиться о базовой инфраструктуре, как Microsoft. Но хост-машины по-прежнему необходимо обслуживать, и сбои будут происходить. Жесткие диски умирают, сетевые карты выходят из строя, гипервизоры нужно исправлять… все, с чем нам приходится иметь дело локально, происходит в дата-центре Microsoft. Вам не нужно разбираться с этим самостоятельно, но пока этим занимается команда Microsoft, вы можете столкнуться с незапланированным отключением. Чтобы ваша виртуальная машина работала и соответствовала SLA, вам необходимо иметь две виртуальные машины в группе доступности. У Microsoft есть дополнительные сведения и инструкции по настройке высокой доступности в Azure. Исключением из этого правила является то, что если вы используете хранилище Premium для операционных дисков и дисков данных виртуальной машины, то применяется SLA 99,99%.

3. Неправильное развертывание виртуальных машин в группе доступности

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

4. Размещение данных там, где их быть не должно

Из-за недавнего предупреждения Microsoft я видел эту ошибку гораздо реже, но это все еще происходит. После создания виртуальной машины вы увидите диск D: объемом более 70 ГБ. В локальной среде мы используем это пространство для хранения данных, однако при этом в Azure ваша система перезагружается из-за обслуживания (см. пункт 2), и все ваши данные исчезают. К сожалению, до недавнего времени эта проблема не была широко известна как проблема. С тех пор Microsoft поместила текстовый файл на диск D: с предупреждением о том, что данные, хранящиеся на этом диске, могут привести к потере данных:

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

5. Отсутствие планирования

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

• Размещение виртуальных машин. Перемещение виртуальных машин между виртуальными сетями — непростая задача. Потратьте время, чтобы спланировать, какие виртуальные машины будут в каких виртуальных сетях перед развертыванием. Вы можете использовать Azure Virtual Machine Backup для повторного развертывания виртуальной машины Azure, если вам нужно переместить виртуальную машину.
• Добавление хостов. Если вы не планируете увеличение количества виртуальных машин, вы можете обнаружить, что ваши подсети не вмещают увеличившееся количество хостов, и вам нужно будет удалить свои подсети, изменить подсеть, которая недостаточно велика, а затем снова создайте последующие подсети. Конкретные ограничения см. в разделе часто задаваемых вопросов по виртуальной сети Azure.
• Виртуальные машины: размер имеет значение. Вот один нюанс, который будет вас преследовать. Облако масштабируется, верно? Вот почему мы размещаем там наши виртуальные машины; мы можем масштабировать их по мере необходимости. По большей части это так, если только вы не создали свою первоначальную виртуальную машину в другом семействе. Например, компьютер Basic_A0 не может масштабироваться до Standard_D1v2. Всегда следите за тем, чтобы выбранную вами виртуальную машину можно было масштабировать до максимального необходимого размера, и чтобы виртуальная машина была доступна в нужном регионе. Имейте в виду, что не все виртуальные машины доступны во всех регионах.

6. Установка статического IP

В локальном мире, как только сервер запущен и работает, мы назначаем ему статический IP-адрес. Если вы сделаете это с виртуальной машиной Azure, вы потеряете подключение к ней. Назначьте статические IP-адреса через портал Azure или PowerShell.

7. Отсутствие резервного копирования данных и виртуальных машин

Это еще один из тех пунктов, о которых мы только что позаботились. Когда вы создаете учетную запись хранения для связи с виртуальной машиной, вы можете выбрать локальное или геоизбыточное хранилище. Локальный означает, что три копии ваших данных размещаются в одном и том же центре обработки данных, а географический поддерживает шесть копий в двух центрах обработки данных в дополнительном регионе. Данные реплицируются и не защищают вас от удаленных или поврежденных данных. Лучше всего создавать резервные копии ваших данных, как мы это делаем локально. Azure Backup может создавать резервные копии ваших файлов и папок, виртуальных машин Azure и файловых ресурсов SMB. Подробные инструкции по реализации сценария Azure Backup, который наилучшим образом соответствует вашим потребностям, см. в документации по Azure Backup.

Остерегайтесь «подводных камней»

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