student - panel azure login
¿Por qué los grupos de recursos de Azure están asociados con una región específica? (5)
Soy nuevo en la arquitectura de Azure y estoy tratando de entender por qué los Grupos de recursos de Azure, que son grupos de implementación lógica para las aplicaciones creadas en Azure, se asocian con una región cuando se definen.
Al principio pensé que era para proporcionar una distribución global para la recuperación de desastres o la redundancia geográfica, pero luego me di cuenta de que un solo grupo de recursos puede contener aplicaciones web en diferentes regiones, que pueden proporcionar esas características a través de Traffic Manager. Supongo que usar grupos de recursos separados ayudaría a identificar mejor qué recursos se encuentran en qué región, pero, aparte de los fines organizativos, no puedo entender lo que implica la definición de la región para grupos de recursos.
(Editar: Se eliminó la consulta de consejos generales para estar más centrado)
Al crear un grupo de recursos, debe proporcionar una ubicación para ese grupo de recursos. Quizás se esté preguntando: "¿Por qué un grupo de recursos necesita una ubicación? Y, si los recursos pueden tener ubicaciones diferentes a las del grupo de recursos, ¿por qué la ubicación del grupo de recursos es importante?" El grupo de recursos almacena metadatos sobre los recursos. Por lo tanto, cuando especifica una ubicación para el grupo de recursos, está especificando dónde se almacenan los metadatos. Por motivos de cumplimiento, es posible que deba asegurarse de que sus datos estén almacenados en una región en particular.
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
Básicamente, los grupos de recursos son para que usted decida qué recursos de la aplicación desea administrar juntos y, por gestión, me refiero a que desea implementarlos, administrarlos y monitorearlos como un grupo, por lo que, a un alto nivel, no los verá como componentes separados.
En general, en un gran ecosistema, los grupos de recursos de Azure son aquellos en los que no ve esos componentes (recursos) en ellos como entidades separadas, en cambio, los ve como partes relacionadas e interdependientes de una sola entidad, por lo que los coloca en un grupo de recursos. de modo que utilizando la herramienta Azure Resource Group Manager Puede implementar, actualizar o eliminar todos los recursos para su aplicación en una sola operación coordinada.
Utiliza una plantilla para la implementación y esa plantilla puede funcionar para diferentes entornos, como pruebas, organización y producción. Puede aclarar la facturación para su organización al ver los costos acumulados para todo el grupo.
Puede encontrar más detalles sobre el Administrador de recursos de Azure aquí, que creo que lo ayudará a comprender mejor la idea detrás de los Grupos de recursos de Azure:
https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/
La razón principal para especificar la ubicación de un grupo de recursos es especificar una ubicación para los datos / metadatos para el almacenamiento que se almacenará en ... También hace que la API sea coherente (piense en las rutas en las llamadas de la API REST), pero la razón principal es el almacenamiento durante la implementación.
La ubicación de los recursos en el grupo es independiente / no está relacionada con la ubicación del propio grupo.
Los metadatos (definición) del grupo de recursos de Azure deben almacenarse en algún lugar. de ahí la ubicación. Sin embargo, los recursos dentro de un grupo de recursos son independientes de la ubicación y se pueden colocar en una región diferente / ubicación. Tenga en cuenta que pueden existir dependencias entre recursos. Una máquina virtual en Europa occidental obviamente también necesita una cuenta de almacenamiento en Europa occidental, pero puede existir una base de datos SQL en el mismo grupo de recursos en el oeste de EE. UU.
Todo en Azure se relaciona con una ubicación física / centro de datos, y ARM no es diferente. Hace poco, no todos los centros de datos admitían ARM, por lo que la razón para elegir tenía aún más sentido. Ahora, como cualquier otro recurso de Azure, la decisión es para que el usuario la tome, a menudo en función de su proximidad requerida al usuario final y / o requisitos geográficos legales.