Administración del ciclo de vida de equipos sin sistema operativo
En este artículo se describe cómo realizar operaciones de administración del ciclo de vida en equipos sin sistema operativo (BMM). Estos pasos deben usarse para solucionar problemas a fin de recuperarse de errores o al realizar acciones de mantenimiento. Entre los comandos para administrar el ciclo de vida del BMM se incluyen:
Precaución
No realice ninguna acción en los servidores de administración sin consultar primero con el personal de soporte técnico de Microsoft. Si lo hace, podría afectar a la integridad del clúster de Operator Nexus.
- Apagar un BMM
- Iniciar un BMM
- Reiniciar un BMM
- Convierta BMM en no programable (acordonamiento sin evacuación)
- Convertir el BMM en no programable (acordonamiento con evacuación)
- Convertir el BMM en programable (desacordonamiento)
- Restablecer la imagen inicial de un BMM
- Reemplazar un BMM
Importante
Las solicitudes de comandos disruptivas en un nodo del plano de control de Kubernetes (KCP) se rechazan si hay otro comando de acción perjudicial que ya se ejecuta en otro nodo KCP o si el KCP completo no está disponible. Esta comprobación se realiza para mantener la integridad de la instancia de Nexus y asegurarse de que varios nodos KCP no se vuelven no operativos a la vez debido a acciones disruptivas simultáneas. Si varios nodos se vuelven no operativos, se interrumpirá el umbral de cuórum correcto del plano de control de Kubernetes.
Las acciones en negrita de la lista anterior se consideran perjudiciales (Apagado, Reinicio, Restablecimiento de imagen inicial y Reemplazo) El acordonamiento sin evacuación no se considera perjudicial. El acordonamiento con evacuación se considera perjudicial.
Como se indica en la instrucción de precaución, la ejecución de acciones en los servidores de administración, especialmente los nodos KCP, solo debe llevarse a cabo en consulta con el personal de soporte técnico de Microsoft.
Requisitos previos
- Instale la versión más reciente de las extensiones de la CLI adecuadas.
- Obtenga el nombre del grupo de recursos de la máquina sin sistema operativo: nombre del grupo de recursos administrados por clústeres (cluster_MRG).
- Obtenga el nombre del equipo sin sistema operativo que requiere una operación de administración del ciclo de vida.
- Asegúrese de que el equipo sin sistema operativo de destino
poweredState
se establece enOn
y de quereadyState
lo hace enTrue
.- Este requisito previo no es aplicable al comando
start
.
- Este requisito previo no es aplicable al comando
Apagar un BMM
Este comando reiniciará mediante power-off
el bareMetalMachineName
especificado.
az networkcloud baremetalmachine power-off \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID>
Iniciar un BMM
Este comando reiniciará mediante start
el bareMetalMachineName
especificado.
az networkcloud baremetalmachine start \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID>
Reiniciar un BMM
Este comando reiniciará mediante restart
el bareMetalMachineName
especificado.
az networkcloud baremetalmachine restart \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID>
Haga que un BMM no se pueda programar (acordonamiento)
Para identificar si alguna carga de trabajo se está ejecutando actualmente en un BMM, ejecute el siguiente comando:
Para Virtual Machines:
az networkcloud baremetalmachine show -n <nodeName> /
--resource-group <resourceGroup> /
--subscription <subscriptionID> | jq '.virtualMachinesAssociatedIds'
Para los nodos de clúster de Nexus Kubernetes: (requiere el inicio de sesión en el clúster de Nexus Kubernetes)
kubectl get nodes <resourceName> -ojson |jq '.metadata.labels."topology.kubernetes.io/baremetalmachine"'
Puede hacer que un BMM no se pueda programar mediante la ejecución del comando cordon
.
En la ejecución del comando cordon
, las cargas de trabajo de Operator Nexus no están programadas en el BMM al establecerse el acordonamiento; cualquier intento de crear una carga de trabajo en un BMM cordoned
da lugar al establecimiento de la carga de trabajo en el estado pending
. Las cargas de trabajo existentes seguirán en ejecución.
El comando de acordonamiento admite un parámetro evacuate
con el valor False
predeterminado.
Un procedimiento recomendado es establecerlo en True
. Al ejecutar el comando cordon
, con el valor True
para el parámetro evacuate
, las cargas de trabajo que se ejecutan en el BMM se detienen mediante stopped
y el BMM se establece en el estado pending
.
az networkcloud baremetalmachine cordon \
--evacuate "True" \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID>
evacuate "True"
quita las cargas de trabajo de ese nodo, mientras que evacuate "False"
solo impide la programación de nuevas cargas de trabajo.
Haga que el BMM "se pueda programar" (desacordonamiento)
Puede hacer que un BMM "se pueda programar" mediante la ejecución del comando uncordon
. Todas las cargas de trabajo con un estado pending
en el BMM se reinician mediante restarted
cuando el BMM se desacordona mediante uncordoned
.
az networkcloud baremetalmachine uncordon \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID>
Restablezca la imagen inicial de un BMM
Puede restaurar la versión del entorno de ejecución en un BMM mediante la ejecución del comando reimage
. Este proceso vuelve a implementar la imagen del entorno de ejecución en el BMM de destino y ejecuta los pasos para volver a unir el clúster con los mismos identificadores. Esta acción no afecta a los archivos de carga de trabajo de inquilino en este BMM. En caso de que se realice una acción de escritura o edición en el nodo a través del acceso BMM, esta acción "restablecer imagen inicial" es necesaria para restaurar la compatibilidad de Microsoft y se perderán los cambios, restaurando el nodo a su estado esperado.
Como procedimiento recomendado, asegúrese de que las cargas de trabajo del BMM se purgan mediante el comando cordon
, con evacuate "True"
, antes de ejecutar el comando reimage
.
Advertencia
Al ejecutar más de un comando baremetalmachine replace
o reimage
al mismo tiempo, o bien replace
al mismo tiempo que reimage
, los servidores quedarán en un estado de no funcionamiento. Asegúrese de que replace
/reimage
se haya completado totalmente antes de iniciar otro.
az networkcloud baremetalmachine reimage \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID>
Reemplazar un BMM
Use el comando replace
cuando un servidor encuentre problemas de hardware que requieran un reemplazo de hardware completo o parcial. Después de reemplazar componentes como el reemplazo de la tarjeta de interfaz de red (NIC) o la placa base, la dirección MAC de BMM cambiará, pero el nombre de host y la dirección IP de iDRAC seguirán siendo los mismos.
Advertencia
Al ejecutar más de un comando baremetalmachine replace
o reimage
al mismo tiempo, o bien replace
al mismo tiempo que reimage
, los servidores quedarán en un estado de no funcionamiento. Asegúrese de que replace
/reimage
se haya completado totalmente antes de iniciar otro.
az networkcloud baremetalmachine replace \
--name <BareMetalMachineName> \
--resource-group <resourceGroup> \
--bmc-credentials password=<IDRAC_PASSWORD> username=<IDRAC_USER> \
--bmc-mac-address <IDRAC_MAC> \
--boot-mac-address <PXE_MAC> \
--machine-name <OS_HOSTNAME> \
--serial-number <SERIAL_NUMBER> \
--subscription <subscriptionID>