Dise\u00f1o de arquitectura de servicios<\/h4>\n
La forma m\u00e1s com\u00fan de construir un sistema escalable, altamente disponible y rico en datos es a trav\u00e9s de bloques de construcci\u00f3n independientes o unidades de escala para el nivel de datos Azure AD, las unidades de escala se llaman particiones<\/em> .<\/p>\n El nivel de datos tiene varios servicios front-end que proporcionan capacidad de lectura-escritura. El diagrama siguiente muestra c\u00f3mo los componentes de una partici\u00f3n de un solo directorio se distribuyen a trav\u00e9s de centros de datos distrubuidos geogr\u00e1ficamente.<\/p>\n Los componentes de la arquitectura Azure AD incluyen una r\u00e9plica primaria y r\u00e9plicas secundarias.<\/p>\n La r\u00e9plica primaria<\/em> recibe todas las escrituras para la partici\u00f3n a la que pertenece. Cualquier operaci\u00f3n de escritura se replica inmediatamente a una r\u00e9plica secundaria en un centro de datos diferente antes de devolver el \u00e9xito a la persona que llama, garantizando as\u00ed la durabilidad geo-redundante de las escrituras.<\/p>\n Replicas secundarias<\/strong><\/p>\n Todas las lecturas de<\/em> directorio se reparan<\/em> desde r\u00e9plicas secundarias<\/em> , que se encuentran<\/em> en centros de datos que est\u00e1n f\u00edsicamente ubicados en diferentes geograf\u00edas. Hay muchas r\u00e9plicas secundarias, ya que los datos se replican asincr\u00f3nicamente. Las lecturas de directorios, como las solicitudes de autenticaci\u00f3n, son atendidas desde centros de datos cercanos a nuestros clientes. Las r\u00e9plicas secundarias son responsables de la escalabilidad de lectura.<\/p>\n Escalabilidad es la capacidad de un servicio para expandirse para satisfacer las crecientes demandas de rendimiento. Escalabilidad de escritura se logra mediante la partici\u00f3n de los datos. La escalabilidad de lectura se logra replicando datos de una partici\u00f3n a m\u00faltiples r\u00e9plicas secundarias distribuidas en todo el mundo.<\/p>\n Las solicitudes de aplicaciones de directorio generalmente se encaminan al centro de datos al que est\u00e1n f\u00edsicamente m\u00e1s cercanas. Las escrituras son redireccionadas de forma transparente a la r\u00e9plica primaria para proporcionar coherencia de lectura y escritura. Las r\u00e9plicas secundarias ampl\u00edan significativamente la escala de las particiones, ya que los directorios suelen estar publicando lecturas la mayor parte del tiempo.<\/p>\n Las aplicaciones de directorio se conectan a los datacenters m\u00e1s cercanos. Esto mejora el rendimiento y, por lo tanto, la ampliaci\u00f3n es posible. Dado que una partici\u00f3n de directorio puede tener muchas r\u00e9plicas secundarias, las r\u00e9plicas secundarias se pueden situar m\u00e1s cerca de los clientes del directorio. S\u00f3lo los componentes de servicio de directorio interno que son de escritura intensiva orientan la r\u00e9plica primaria activa directamente.<\/p>\n \n \n \n \n Disponibilidad (o tiempo de actividad) define la capacidad de un sistema para realizar ininterrumpido. La clave para la alta disponibilidad de Azure AD es que nuestros servicios pueden cambiar r\u00e1pidamente el tr\u00e1fico a trav\u00e9s de m\u00faltiples centros de datos distribuidos geogr\u00e1ficamente. Cada centro de datos es independiente, lo que permite los modos de fallo de correlaci\u00f3n.<\/p>\n El dise\u00f1o de la partici\u00f3n Azure AD se simplifica en comparaci\u00f3n con el dise\u00f1o AD de la empresa, que es cr\u00edtico para ampliar el sistema. Hemos adoptado un dise\u00f1o de un solo maestro que incluye un proceso de conmutaci\u00f3n por error de r\u00e9plica primario cuidadosamente orquestado y determinista.<\/p>\n Tolerancia a fallos<\/strong><\/p>\n Un sistema est\u00e1 m\u00e1s disponible si es tolerante a fallas de hardware, red y software. Para cada partici\u00f3n en el directorio, existe una r\u00e9plica maestra altamente disponible: La r\u00e9plica primaria. S\u00f3lo se realizan escrituras en la partici\u00f3n en esta r\u00e9plica. Esta r\u00e9plica se est\u00e1 supervisando continuamente y de cerca y las escrituras pueden ser cambiadas inmediatamente a otra r\u00e9plica (que se convierte en la nueva primaria) si se detecta un fallo. Durante la conmutaci\u00f3n por error, podr\u00eda haber una p\u00e9rdida de la disponibilidad de escritura normalmente de 1-2 minutos. La disponibilidad de lectura no se ve afectada durante este tiempo.<\/p>\n Las operaciones de lectura (que superan en n\u00famero a las escrituras por muchos \u00f3rdenes de magnitud) s\u00f3lo van a r\u00e9plicas secundarias. Dado que las r\u00e9plicas secundarias son idempotentes, la p\u00e9rdida de una r\u00e9plica en una partici\u00f3n dada se puede compensar f\u00e1cilmente dirigiendo las lecturas a otra r\u00e9plica, normalmente en el mismo centro de datos.<\/p>\n Una escritura est\u00e1 comprometida de forma duradera con al menos dos centros de datos antes de que se reconozca. Esto ocurre al confirmar primero la escritura en el primario y luego replicar inmediatamente la escritura en al menos otro centro de datos. Esto garantiza que una posible p\u00e9rdida catastr\u00f3fica del centro de datos que aloje el primario no resulte en p\u00e9rdida de datos.<\/p>\n Azure AD mantiene un objetivo de cero Recovery Time Objective (RTO)<\/a> para la emisi\u00f3n de token y lecturas de directorios y en el orden de minutos (~ 5 minutos) RTO para escrituras de directorios. Tambi\u00e9n mantiene el objetivo de cero Recovery Point Objective (RPO)<\/a> y no perderemos datos sobre failovers.<\/p>\n Las r\u00e9plicas de Azure AD se almacenan en centros de datos ubicados en todo el mundo. Azure AD opera a trav\u00e9s de centros de datos con las siguientes caracter\u00edsticas:<\/p>\n El modelo de directorio es de consistencia eventual. Un problema t\u00edpico con sistemas de replicaci\u00f3n asincr\u00f3nicos distribuidos es que los datos devueltos de una r\u00e9plica "particular" pueden no estar actualizados.<\/p>\n Azure AD proporciona coherencia de lectura y escritura para las aplicaciones que apuntan a una r\u00e9plica secundaria, enrutando sus escrituras a la r\u00e9plica primaria y transfiriendo de forma s\u00edncrona las escrituras a la r\u00e9plica secundaria. Las escrituras de aplicaciones que utilizan la Graph API de Azure AD se abstraen de mantener la afinidad con una r\u00e9plica de directorio para la coherencia de lectura y escritura. El servicio Azure AD Graph mantiene una sesi\u00f3n l\u00f3gica, que tiene afinidad con una r\u00e9plica secundaria utilizada para lecturas; La afinidad se captura en un "token de r\u00e9plica" que el servicio de gr\u00e1fico almacena en cach\u00e9 utilizando una cach\u00e9 distribuida. Este token se utiliza entonces para operaciones posteriores en la misma sesi\u00f3n l\u00f3gica.<\/p>\n El directorio implementa borrados suaves, en lugar de eliminaciones duras, para usuarios y inquilinos para una f\u00e1cil recuperaci\u00f3n en caso de borrados accidentales por parte de un cliente. Si el administrador de su inquilino borra accidentalmente a los usuarios, puede deshacer y restaurar f\u00e1cilmente los usuarios eliminados.<\/p>\n Azure AD implementa copias de seguridad diarias de todos los datos y, por lo tanto, puede restaurar los datos de forma autoritaria en caso de cualquier supresi\u00f3n o corrupci\u00f3n l\u00f3gica. Nuestro nivel de datos emplea c\u00f3digos de correcci\u00f3n de errores, de modo que puede comprobar errores y corregir autom\u00e1ticamente determinados tipos de errores de disco.<\/p>\n La ejecuci\u00f3n de un servicio de alta disponibilidad requiere m\u00e9tricas de nivel mundial y capacidades de monitoreo. Azure AD analiza e informa continuamente las m\u00e9tricas clave de salud de servicio y los criterios de \u00e9xito para cada uno de sus servicios. Desarrollamos y sintonizamos continuamente m\u00e9tricas, monitoreo y alertas para cada escenario, dentro de cada servicio Azure AD y en todos los servicios.<\/p>\n Si cualquier servicio Azure AD no funciona como se espera, inmediatamente tomamos medidas para restaurar la funcionalidad lo m\u00e1s r\u00e1pido posible. La pista m\u00e9trica m\u00e1s importante de Azure AD es la rapidez con que podemos detectar y mitigar un problema de cliente o sitio en vivo. Invertimos mucho en el monitoreo y las alertas para minimizar el tiempo de detecci\u00f3n (objetivo TTD: <5 minutos) y la preparaci\u00f3n operativa para minimizar el tiempo para mitigar (objetivo TTM: <30 minutos).<\/p>\n Empleamos controles operativos tales como autenticaci\u00f3n de m\u00faltiples factores (MFA) para cualquier operaci\u00f3n, as\u00ed como auditor\u00eda de todas las operaciones. Adem\u00e1s, utilizamos un sistema de elevaci\u00f3n just-in-time para conceder el acceso temporal necesario para cualquier tarea operativa bajo demanda en forma continua. <\/p>\n Para mas informaci\u00f3n les dejo un video sobre el tema que es super interesante. Saludos. Roberto Di Lello<\/p>\n ![\"active-directory-architecture\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2017\/e204ce7959bb_BCC8\/active-directory-architecture.png\" "\\"active-directory-architecture\\"")
<\/a><\/p>\nR\u00e9plica primaria<\/h4>\n
Escalabilidad<\/h4>\n
Disponibilidad continua<\/h4>\n
Durabilidad de los datos<\/h4>\n
Centros de datos<\/h4>\n
\n
Consistencia de los datos<\/h4>\n
Protecci\u00f3n de copia de seguridad<\/h4>\n
M\u00e9tricas y monitores<\/h4>\n
Operaciones seguras<\/h4>\n