Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Пользовательские метрики для последовательного обновления позволяют использовать расширение работоспособности приложения для отправки пользовательских метрик в масштабируемый набор виртуальных машин. Эти пользовательские метрики можно использовать для определения масштабируемого набора порядка обновления виртуальных машин при активации последовательного обновления. Пользовательские метрики также могут информировать масштабируемый набор, когда обновление должно быть пропущено в определенном экземпляре. Это позволяет более контролировать порядок и сам процесс обновления.
Пользовательские метрики можно использовать в сочетании с другими функциональными возможностями последовательного обновления, такими как автоматическое обновление ОС, автоматическое обновление расширений и последовательное обновление MaxSurge.
Требования
- При использовании пользовательских метрик для последовательного обновления в Масштабируемые наборы виртуальных машин масштабируемый набор также должен использовать расширение работоспособности приложения с расширенными состояниями работоспособности для создания отчетов о порядке этапов или пропускания сведений об обновлении. Обновления пользовательских метрик не поддерживаются при использовании расширения работоспособности приложения с двоичными состояниями.
- Расширение работоспособности приложения должно быть настроено для использования HTTP или HTTPS для получения пользовательских сведений о метриках. Tcp не поддерживается для интеграции с пользовательскими метриками для последовательного обновления.
Основные понятия
Порядок этапов
Этап — это конструкция группирования для виртуальных машин. Каждый этап определяется настройкой метаданных, создаваемых расширением работоспособности приложения через customMetrics свойство. Масштабируемый набор виртуальных машин принимает сведения, полученные из пользовательских метрик, и использует его для размещения виртуальных машин на назначенных этапах. На каждом этапе масштабируемый набор виртуальных машин также назначает пакеты обновления. Каждый пакет настраивается с помощью политики последовательного обновления, которая учитывает домены обновления (UD), домены сбоя (FD) и сведения о зонах каждой виртуальной машины.
При запуске последовательного обновления виртуальные машины помещаются в назначенные этапы. Поэтапное обновление выполняется в порядке числовых последовательностей. Виртуальные машины во всех пакетах на этапе будут завершены перед переходом к следующему этапу. Если для виртуальной машины не получено порядок этапов, масштабируемый набор помещается на последний этап.
Схема регионального (
Схема масштабируемого набора зон
Чтобы указать номер этапа, с которым должна быть связана виртуальная машина, используйте phaseOrderingNumber параметр.
{
“applicationHealthState”: “Healthy”,
“customMetrics”: "{ \"rollingUpgrade\": { \"PhaseOrderingNumber\": 0 } }"
}
Пропустить обновление
Пропустить функцию обновления позволяет опущению отдельного экземпляра во время последовательного обновления. Это похоже на использование защиты экземпляров, но может более легко интегрироваться в рабочий процесс последовательного обновления и в приложения уровня экземпляров. Как и порядок этапов, сведения об обновлении пропуска передаются в масштабируемый набор виртуальных машин с помощью расширения работоспособности приложения и пользовательских параметров метрик. При активации последовательного обновления масштабируемый набор виртуальных машин проверяет ответ пользовательских метрик расширения работоспособности приложения и если обновление пропускается в значение true, экземпляр не включен в последовательное обновление.
Для пропуска обновления на виртуальной машине используйте SkipUpgrade параметр. Это указывает на последовательное обновление, чтобы пропустить эту виртуальную машину при выполнении обновлений.
{
“applicationHealthState”: “Healthy”,
“customMetrics”: "{ \"rollingUpgrade\": { \"SkipUpgrade\": true} }"
}
Пропустить порядок обновления и этапа также можно использовать вместе:
{
“applicationHealthState”: “Healthy”,
“customMetrics”: "{ \"rollingUpgrade\": { \"SkipUpgrade\": false, \"PhaseOrderingNumber\": 0 } }"
}
Настройка расширения работоспособности приложения
Для расширения работоспособности приложения требуется HTTP-запрос или HTTPS с соответствующим портом или путем запроса. Пробы TCP поддерживаются при использовании расширения работоспособности приложения, но не могут задаваться ApplicationHealthState в теле отклика пробы и не могут использоваться при последовательном обновлении с пользовательскими метриками.
{
"extensionProfile" : {
"extensions" : [
{
"name": "HealthExtension",
"properties": {
"publisher": "Microsoft.ManagedServices",
"type": "<ApplicationHealthLinux or ApplicationHealthWindows>",
"autoUpgradeMinorVersion": true,
"typeHandlerVersion": "2.0",
"settings": {
"protocol": "<protocol>",
"port": <port>,
"requestPath": "</requestPath>",
"intervalInSeconds": 5,
"numberOfProbes": 1
}
}
}
]
}
}
| Имя. | Значение и пример | Тип данных |
|---|---|---|
| протокол |
http или https |
строка |
| порт | Необязательный вариант, если протокол или httphttps |
INT |
| путь запроса | Обязательный при использовании http или https |
строка |
| интервалВСекундах | Необязательно, значение по умолчанию — 5 секунд. Этот параметр является интервалом между каждой пробой работоспособности. Например, если интервалInSeconds == 5, проба отправляется в локальную конечную точку приложения каждые 5 секунд. | INT |
| количествоПроб.Тестов | Необязательно, значение по умолчанию — 1. Этот параметр — это количество последовательных проб, необходимых для изменения состояния работоспособности. Например, если numberOfProbles == 3, вам потребуется 3 последовательных сигналов "Работоспособность" для изменения состояния работоспособности с "Неработоспособное"/"Неизвестно" в состояние "Работоспособность". Это же требование применяется к изменению состояния работоспособности на состояние "Неработоспособное" или "Неизвестно". | INT |
| льготный период | Необязательный, по умолчанию = intervalInSeconds * numberOfProbes; максимальный льготный период составляет 7200 секунд |
INT |
Установка расширения работоспособности приложения
Используйте az vmss extension set , чтобы добавить расширение работоспособности приложения в определение модели масштабируемого набора.
Создайте json-файл, вызываемый extensions.json с нужными параметрами.
{
"protocol": "<protocol>",
"port": <port>,
"requestPath": "</requestPath>",
"gracePeriod": <healthExtensionGracePeriod>
}
Примените расширение работоспособности приложения.
az vmss extension set \
--name ApplicationHealthLinux \
--publisher Microsoft.ManagedServices \
--version 2.0 \
--resource-group myResourceGroup \
--vmss-name myScaleSet \
--settings ./extension.json
Обновите виртуальные машины в масштабируемом наборе. Этот шаг требуется только в том случае, если масштабируемый набор использует политику обновления вручную. Дополнительные сведения о политиках обновления см. в политиках обновления для Масштабируемые наборы виртуальных машин
az vmss update-instances \
--resource-group myResourceGroup \
--name myScaleSet \
--instance-ids "*"
Настройка ответа расширения работоспособности приложения
Настройка ответа пользовательских метрик может выполняться различными способами. Он может быть интегрирован в существующие приложения, динамически обновляться и использоваться вместе с различными функциями для предоставления выходных данных в зависимости от конкретной ситуации.
Эти примеры приложений включают порядок этапов и пропускают параметры обновления в ответ пользовательских метрик.
#!/bin/bash
# Open firewall port (replace with your firewall rules as needed)
sudo iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
# Create Python HTTP server for responding with JSON
cat <<EOF > server.py
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
# Function to generate the JSON response
def generate_response_json():
return json.dumps({
"ApplicationHealthState": "Healthy",
"CustomMetrics": json.dumps({
"RollingUpgrade": {
"PhaseOrderingNumber": 1,
"SkipUpgrade": "false"
}
})
})
class RequestHandler(BaseHTTPRequestHandler):
def do_GET(self):
# Respond with HTTP 200 and JSON content
self.send_response(200)
self.send_header('Content-type', 'application/json')
self.end_headers()
response = generate_response_json()
self.wfile.write(response.encode('utf-8'))
# Set up the HTTP server
def run(server_class=HTTPServer, handler_class=RequestHandler):
server_address = ('localhost', 8000)
httpd = server_class(server_address, handler_class)
print('Starting server on port 8000...')
httpd.serve_forever()
if __name__ == "__main__":
run()
EOF
# Run the server in the background
python3 server.py &
# Store the process ID of the server
SERVER_PID=$!
# Wait a few seconds to ensure the server starts
sleep 2
# Confirm execution
echo "Server has been started on port 8000 with PID $SERVER_PID"
Дополнительные примеры конфигурации ответа см . в примерах работоспособности приложений
Проверка и запрос пользовательских метрик
После настройки расширения работоспособности приложения для возврата пользовательских метрик, вы можете убедиться, что пользовательские метрики передаются правильно, и запросить данные из экземпляров масштабируемого набора виртуальных машин.
Замечание
Метод запроса пользовательских метрик отличается от режимов универсальной и гибкой оркестрации. Универсальный режим используется az vmss get-instance-view, в то время как гибкий режим требует запроса отдельных виртуальных машин с помощью az vm get-instance-view.
Для единого режима оркестрации
az vmss get-instance-view \
--resource-group <resource-group-name> \
--name <vmss-name> \
--instance-id <instance-id>
Пример выходных данных (фрагмент):
{
"extensions": [
{
"name": "ApplicationHealthExtension",
"substatuses": [
{
"code": "ComponentStatus/CustomMetrics/succeeded",
"message": "{\"rollingUpgrade\": {\"PhaseOrderingNumber\": 2, \"SkipUpgrade\": false}}"
}
]
}
]
}
Пользовательские метрики находятся в message поле подстатуса ComponentStatus/CustomMetrics/succeeded.
Режим гибкой оркестрации
В режиме гибкой оркестрации экземпляры являются отдельными виртуальными машинами. Используйте команду и укажите имя виртуальной az vm get-instance-view машины.
Получите пользовательские метрики для конкретной виртуальной машины:
az vm get-instance-view \
--resource-group <resource-group-name> \
--name <vm-name>
Пример выходных данных (фрагмент):
{
"extensions": [
{
"name": "ApplicationHealthExtension",
"substatuses": [
{
"code": "ComponentStatus/CustomMetrics/succeeded",
"message": "{\"rollingUpgrade\": {\"PhaseOrderingNumber\": 1, \"SkipUpgrade\": false}}"
}
]
}
]
}
Пользовательские метрики находятся в message поле подстатуса ComponentStatus/CustomMetrics/succeeded.
Устранение неполадок с пользовательскими метриками
Если пользовательские метрики не передаются правильно, проверьте следующее:
- Проверьте состояние расширения работоспособности приложения:
az vmss get-instance-view \
--resource-group <resource-group-name> \
--name <vmss-name> \
--instance-id <instance-id> \
--query "extensions[?name=='ApplicationHealthExtension'].statuses"
- Убедитесь, что точка проверки работоспособности отвечает:
# Get the public IP of an instance
PUBLIC_IP=$(az vmss list-instance-public-ips \
--resource-group <resource-group-name> \
--name <vmss-name> \
--query "[0].ipAddress" \
--output tsv)
# Test the health endpoint
curl -v http://$PUBLIC_IP:<port>/<request-path>
- Проверьте правильность формата ответа:
Конечная точка работоспособности приложения должна возвращать ответ JSON в этом точном формате:
{
"ApplicationHealthState": "Healthy",
"customMetrics": "{\"rollingUpgrade\": {\"PhaseOrderingNumber\": 0, \"SkipUpgrade\": false}}"
}
Это важно
- Значение
customMetricsдолжно быть строкой JSON (двойной сериализации), а не объектом JSON -
ApplicationHealthStateдолжен быть установлен на "Исправно", чтобы экземпляр был включен в последовательное обновление. - Пользовательские метрики считываются только в начале последовательного обновления; изменения во время обновления не повлияют на текущее обновление.
Следующие шаги
Узнайте, как выполнять обновления вручную на Масштабируемые наборы виртуальных машин.