Compartir a través de


Restauración de un servidor de nivel de aplicación

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

Las bases de datos de Azure DevOps almacenan todos los datos de la implementación de Azure DevOps Server. Incluso si realiza una copia de seguridad del servidor de nivel de aplicación, no realizará ninguna copia de seguridad de los datos de Azure DevOps Server. Sin embargo, si se produce un error en el hardware de un servidor de nivel de aplicación, puede instalar otro servidor de capa de aplicación y configurarlo para usar las bases de datos de la implementación. Ese servidor reemplazará el servidor sin conexión como servidor de nivel de aplicación para la implementación. Si el servidor de nivel de aplicación hospeda productos de SharePoint, también debe restaurar ese software en el nuevo hardware. Para obtener más información, vea Copia de seguridad (SharePoint Foundation), Copia de seguridad y recuperación (SharePoint Server) o Protección y restauración de una granja de servidores (Office SharePoint Server 2007).

Nota:

Después de restaurar un nivel de aplicación en un nuevo hardware, compruebe que todos los usuarios, grupos y cuentas de servicio de la implementación están configurados con los permisos necesarios para realizar las tareas necesarias. Por ejemplo, los administradores de Azure DevOps deben ser miembros del grupo administradores local en el servidor de nivel de aplicación para que puedan abrir la consola de administración. Para más información, consulte Incorporación de usuarios a proyectos, Establecimiento de permisos de administrador para colecciones de proyectos, Establecimiento de permisos de administrador para Azure DevOps Server y cuentas de servicio y dependencias en Azure DevOps Server.

También puede agregar más de un servidor de nivel de aplicación a una implementación de Azure DevOps Server, pero debe configurar los clientes para conectarse a ese servidor como un nivel de aplicación independiente. No se puede configurar el equilibrio de carga automático entre servidores de nivel de aplicación. Para el equilibrio de carga y la transparencia a los clientes, primero debe instalar y configurar un dispositivo de hardware o software para el equilibrio de carga de red (NLB).

Para instalar y configurar un servidor como servidor de nivel de aplicación

  1. Detenga los grupos de aplicaciones y los servicios que usa Azure DevOps Server.

    Para obtener más información, vea Comando TFSServiceControl.

  2. Si usa servicio de red como cuenta de servicio para Azure DevOps (TFSService), en el servidor de nivel de aplicación, abra una ventana del símbolo del sistema y cambie los directorios a Drive:%programfiles%\Azure DevOps Server 2019\Tools. En el símbolo del sistema, escriba el siguiente comando:

    Cuentas tfsConfig /add /account:"NT Authority\Network Service" /accountType:ApplicationTier /SQLInstance: ServerName /DatabaseName: DatabaseName

    Nota:

    Para obtener más información, vea Comando Cuentas.

  3. Instale Azure DevOps Server en el nuevo servidor e inicie el asistente solo de nivel de aplicación.

  4. Si usa Visual Studio Lab Management, instale la consola de administrador de System Center Virtual Machine Manager (SCVMM) en el nivel de aplicación y configúrela para conectarse al servidor que ejecuta SCVMM.

    Para obtener más información, consulte Configuring Lab Management for SCVMM environments (Configuración de lab Management para entornos SCVMM).

  5. Si el nombre del equipo ha cambiado, abra la consola de administración para Azure DevOps.

  6. En la barra de navegación, seleccione Nivel de aplicación y, a continuación, seleccione Cambiar direcciones URL.

    Se abre la ventana Cambiar direcciones URL .

  7. En Dirección URL de notificación, especifique la dirección URL del nuevo servidor de capa de aplicación y, a continuación, seleccione Aceptar.

    Nota:

    El nombre del servidor de nivel de aplicación anterior seguirá apareciendo en la lista de servidores de nivel de aplicación en la consola de administración de Azure DevOps. Si activa la casilla Filtrar máquinas que no se han conectado en más de 3 días , el servidor antiguo desaparecerá de la lista en un plazo de tres días.