MVC: Planifica las capas

Después de esta lección, usted podrá:

    • Planificar el acceso a datos
    • Planificar SoC (Separation Of Concern) Separación de intereses
    • Usar modelos, vistas y controladores apropiadamente
    • Elegir entre el lado del cliente y el procesamiento del lado del servidor
    • Diseñar para escalabilidad


    TIEMPO ESTIMADO: 20 MINUTOS

Podcast

PLANIFICAR EL ACCESO A DATOS

Aplicación? 

Una aplicación ASP.NET MVC posee un diseño arquitectónico o patrón Modelo-Vista-Controlador (MVC). Una aplicación es simplemente un conjunto de funcionalidades: una pantalla o un conjunto de pantallas que muestra información, una forma de conservar datos entre usos y una forma de tomar decisiones comerciales.

Capa?

Una capa es una agrupación lógica de código que funciona en conjunto como un interes común. Las capas trabajan juntas para producir la aplicación completa.

Opciones de acceso a datos

Después de determinar los requisitos de datos (datos existentes, datos nuevos o una combinación), considere cómo necesita acceder a los datos. Las dos opciones principales son:

  1. Uso de un asignador relacional de objetos (ORM, Objet Relational Model)   Un ORM es una aplicación o sistema que ayuda en la conversión de datos dentro de un sistema de administración de bases de datos relacionales (RDBMS), alimentando el objeto con los datos de la base de datos, o crea las declaraciones SQL que guardarán los datos del objeto en la base de datos. Por ejemplo, Entity Framework y Linq-to-SQL.
  2. Escribir su propio componente para gestionar las interacciones con la  base de datos   Debe gestionar las conversiones desde y hacia su modelo de objetos. Este enfoque puede ser preferible cuando se trabaja con un modelo de datos que no modela de cerca su modelo de objetos, o si se está utilizando un formato de base de datos que no es puramente relacional, como NoSQL.

Enfoques de diseño

Existen dos alternativas:

  1. Utilizando ADO.NET para acceder a su base de datos. Se verá mínimamente afectado si el esquema de datos existe o no.
  2. Utilizando un ORM, su flexibilidad estará limitada por la herramienta que utilice:
    1. Linq-to-SQL, por ejemplo, funciona solo con bases de datos preexistentes; no ofrece soporte para construir el modelo de objetos y usarlo para crear una base de datos.
    2. Entity Framework permite escribir el modelo como parte de su proceso de diseño de negocio y luego crear la base de datos a partir de ese modelo. Y también a partir de un modelo de datos existente,

Entity Framework

«Entity Framework es la tecnología de acceso a datos recomendada de Microsoft para bases de datos relacionales»
Permite MAPEAR los elementos de una DBS, con relación a las Entidades o Clases en una aplicación.
«Entity Framework (EF) es un mapeador relacional de objetos que permite a los desarrolladores de .NET trabajar con datos relacionales utilizando objetos específicos de dominio. Elimina la necesidad de la mayoría del código de acceso a datos que los desarrolladores normalmente necesitan para escribir« 1

ESQUEMAS DE DISEÑO

Hay tres formas de trabajar con datos en Entity Framework:

  1. Código primero
  2. Base de datos primero
  3. Modelo primero (edmx)

Entity Framework es compatible con los enfoques de diseño Model First, Code First y Database First.

Model First y Code First ofrecen una forma diferente de vincular objetos con una base de datos.

ENFOQUE MODEL FIRST

Un arquitecto de software, utiliza el enfoque Model First cuando diseña la base de datos y el modelo de objetos al mismo tiempo con Entity Designer en Microsoft Visual Studio. Esta fue una de las características más solicitadas después del lanzamiento inicial de Entity Framework porque los nuevos proyectos tienden a necesitar nuevos esquemas de base de datos.

El uso de una herramienta de modelado visual, como se observa en la siguiente imagen,  ayuda a los desarrolladores a diseñar el objeto y el modelo de datos apropiados. Se inicia entonces creando un archivo tipo edmx.

ENFOQUE CODE FIRST

Entity Framework también es compatible con el diseño de un nuevo esquema de datos a través de Code First, un proceso en el cual arquitecto de software escribe las clases simples, y el generador de .Net construye la base de datos de esas clases.

Hacer esto permite al equipo de desarrollo diseñar la estructura de objetos, en código, que mejor se adapte a su aplicación y generar la base de datos a partir de ese diseño. Se realiza fuera del Diseñador de la Entidad. Puede atribuir las propiedades del modelo para controlar la configuración de la base de datos, lo que le permite controlar elementos como el nombre de la tabla o columna en la base de datos, longitud máxima, valores predeterminados, claves, ID generados por la base de datos y otros características.

Al planear el diseño de su aplicación, debe evaluar el estado actual de sus datos. Si está trabajando en una actualización o conversión, recomendamos el enfoque de Base de datos, que le permite continuar utilizando la estructura existente sin impacto en la base de datos. Sin embargo, si está creando un nuevo esquema de base de datos, puede elegir el enfoque que mejor se adapte a su equipo de desarrollo. Algunos equipos prefieren usar Entity Designer; otros prefieren conceptualizar el modelo de objetos utilizando una herramienta de terceros o una pizarra.

ENFOQUE ESQUEMA DATABA BASE FIRST

Otros equipos funcionan mejor cuando se diseña la base de datos primero. Sus consideraciones en este punto probablemente serán menos sobre la tecnología y más sobre su diseño de base de datos actual y las preferencias y fortalezas del equipo.

Hay varias cosas a tener en cuenta al considerar el ciclo de vida de su implementación:

  • Model First y Code First son los más sólidos en la creación del esquema de base de datos inicial. Mantener el esquema es más problemático.
  • Aunque ambas herramientas han mejorado su capacidad para administrar actualizaciones de bases de datos, la mayoría de los equipos tienden a usar el enfoque Model First o Code First para la conexión inicial y luego adoptan un enfoque más Database First para actualizaciones en la base de datos y luego actualizan el archivo edmx de la base de datos para refresacar las actualizaciones.

ACCESO A DATOS : La persistencia de los datos

Después de seleccionar los medios por los cuales administrará su diseño de base de datos inicial, debe considerar el enfoque para acceder a los datos desde dentro de su código.

Entity Framework se basa en la clase DBContext , que es una abstracción de la base de datos que gestiona la consulta de datos.

Sin embargo, DBContext se se basa en varias características administradas y banderas que realizan un seguimiento de los cambios en los elementos que se han consultado desde el almacén de datos. Se basa en banderas para determinar la mejor manera de persistir en la información.

Debe elegir un método diferente para controlar el flujo de datos en DBContext  y, por lo tanto, en su base de datos. Debido a que se debe realizar un trabajo adicional fuera de Entity Framework, debe evaluar si desea hacer este trabajo en su (s) controlador (es) o proporcionar un nivel de abstracción entre sus controladores y Entity Framework.

La solución? Un repositorio de datos

EL REPOSITORIO

El patrón de acceso a datos primario en C # es el patrón Repositorio, que está destinado a crear una capa de abstracción entre la capa de acceso a datos y la capa de lógica de negocios.

Permite manejar cualquier cambio en la lógica comercial o en la capa de acceso a los datos al romper las dependencias entre los dos.

También permite que la capa de lógica de negocios acceda al repositorio sin conocer el tipo específico de datos al que está accediendo, como una listas o datos diseñadas en otras aplicaciones.

Lo que el repositorio (capa de persistencia) hace internamente es independiente de la capa de lógica de negocios.
«Los patrones de repositorio y unidad de trabajo están destinados a crear una capa de abstracción entre la capa de acceso a datos y la capa de lógica de negocios de una aplicación. La implementación de estos patrones puede ayudar a aislar su aplicación de los cambios en el almacén de datos y puede facilitar las pruebas unitarias automatizadas o el desarrollo impulsado por pruebas (TDD).» 1

El patrón Repositorio también es muy útil en las pruebas unitarias porque le permite sustituir la conexión de datos real con un repositorio simulado que proporciona datos bien conocidos.

Otro término que puede describir el repositorio es capa de persistencia. La capa de persistencia trata con datos persistentes (almacenamiento y recuperación) de un almacén de datos.

Al utilizar el patrón Repositorio, crea la interfaz y la clase del repositorio. Cuando necesite usar el repositorio, crea una instancia de la interfaz en lugar de la clase. Esto le permite usar la conexión de datos cuando realiza trabajo en el repositorio de simulacro durante la prueba. Agregar el patrón Unidad de trabajo le permite coordinar el trabajo de varios repositorios creando una sola clase compartida para todos ellos.

Tiene muchas formas diferentes de implementar un repositorio: puede crear un repositorio global para todos los datos, un repositorio para cada entidad o alguna combinación.

LA SEPARACIÓN DE INTERESES  (SoC)

Es un concepto de desarrollo de software que separa un programa de computadora en diferentes secciones, intereses o preocupaciones, en las que cada interese o asunto tiene un propósito diferente. Al separar estas secciones, cada una puede encapsular información que puede desarrollarse y actualizarse de manera independiente.  Los modelos multicapas son ejemplo de esto.

ASP.NET MVC agrega un nivel de intereses/preocupación debido a la naturaleza de navegación web basada en el cliente. El hecho de admitir JavaScript en el navegador significa que hay dos partes de la UI que el desarrollador debe considerar: la parte de la IU creada y representada en el servidor y la parte afectada únicamente por el código del lado del cliente.

Aunque la adición de SoC agrega cierta complejidad al diseño de la aplicación, los beneficios superan la complejidad adicional.

El acoplamiento débil: reducción de interdependencias!

Un término estrechamente asociado con SoC es el acoplamiento flexible.

El acoplamiento débil es un enfoque arquitectónico en el cual el diseñador busca limitar la cantidad de interdependencias entre varias partes de un sistema. Al reducir las interdependencias, es menos probable que los cambios en un área de una aplicación afecten a otra área. Además, al eliminar las interdependencias, se asegura de que su aplicación sea más fácil de mantener, comprobable y flexible, lo que tiende a generar un sistema más estable.

UTILICE EL MODELO MVC APROPIADO! 1

El uso apropiado de modelos, vistas y controladores en una aplicación ASP.NET MVC es crítico para tener una aplicación bien diseñada. 

MODELO

El modelo es la parte de la aplicación que maneja la lógica empresarial. Un objeto modelo gestiona el acceso a los datos y realiza la lógica empresarial de los datos.

Enfoques

En general, puede construir su modelo, dominio, vista o modelo de entrada de diferentes maneras.

  1. Enfoque de Dominio: Utiliza un modelo de dominio cuando el objeto está utilizando los datos con los que trabaja en el nivel medio de esa aplicación. Si está utilizando Entity Framework, por ejemplo, y presenta estos objetos a una vista para mostrar, está utilizando un enfoque de modelo de dominio para crear su modelo.
  2. Enfoque de Vista: Un enfoque de modelo de vista describe los datos que se están trabajando en la capa de presentación. Todos los datos que presente en la vista se encuentran dentro de las propiedades de la clase de modelo de vista, que representa todos los datos que el controlador transmite a la vista después de procesar la solicitud. Un modelo de vista generalmente es el resultado de agregar múltiples clases en un solo objeto.
  3. Enfoque de Entrada: El modelo de entrada representa fielmente los datos que se cargan al servidor desde el cliente con cada solicitud HTTP individual. El enfoque del modelo de entrada utiliza el enlace del modelo para capturar la entrada del usuario. Cuando considera un formulario de entrada de datos complejo típico, puede tener un formulario de entrada que capture información que normalmente abarcaría varios objetos en un dominio, como nombre, dirección, empleadores, números de teléfono y otros valores. Esos objetos se asignarían a diferentes objetos de dominio. Sin embargo, el uso de un modelo de entrada permite que todo el trabajo cree y administre estos objetos de dominio para permanecer dentro de un solo controlador y modelo.

CONTROLADORES

Los controladores son parte de ASP.NET MVC que maneja las solicitudes entrantes, maneja la entrada e interacción del usuario y ejecuta la lógica de la aplicación. Un controlador llama al modelo para obtener los objetos comerciales requeridos, si los hay, y luego llama a la vista, ya sea con o sin un modelo, para crear y representar el lenguaje de marcado de hipertexto de salida (HTML).

Un controlador se basa en la clase ControllerBase y es responsable de localizar el método de acción apropiado para llamar y validar que se puede invocar el método de acción, obtener valores en el modelo para usar como parámetros, administrar todos los errores y llamar al motor de visualización para escribir la pagina.  Es el controlador principal de la interacción del usuario.

Las páginas ASP.NET generan y gestionan eventos entre el navegador y la página web, mientras que las aplicaciones ASP.NET MVC están organizadas en torno a controladores y métodos de acción.

Los métodos de acción 

Suelen ser asignaciones de uno a uno a las interacciones del usuario. Cada interacción del usuario crea y llama a un localizador uniforme de recursos (URL). El motor de enrutamiento analiza la URL utilizando las reglas de enrutamiento para determinar el controlador y el método de acción que debe invocarse.

Debido a que los métodos de acción se correlacionan con las interacciones del usuario, se llama a un método de acción cada vez que un usuario hace algo que interactúa con el servidor.

El diseño web tradicional ha adoptado un enfoque de paginación, en el que se presenta un conjunto de características en una página individual. ASP.NET Web Forms, por ejemplo, usa esa metodología, en la cual la lógica de implementación de una página se maneja en esa página. Aunque este diseño dificulta la comunicación entre páginas, actúa como un mecanismo incorporado para gestionar el diseño. Si necesita crear una página para que los usuarios administren un widget, puede hacerlo. Siempre que un usuario necesite crear un widget, lo redireccionará a esa página.

Con ASP.NET MVC, Una forma de ver un controlador es como una forma de separar la funcionalidad.

Puede crear una aplicación grande y compleja con docenas de pantallas usando un solo controlador.

El HomeController

Maneja las vistas de las páginas Acerca de, Contacto e Inicio al usar una acción para cada página.

Un mejor enfoque al diseñar la estructura del controlador es tener un controlador para cada tipo de objeto con el que el usuario interactuará en la pantalla.

Esto le permite dividir en compartimentos la funcionalidad alrededor del objeto en un solo lugar, simplificando la administración del código y proporcionando URL más fáciles de entender.

El mejor momento para conceptualizar la estructura de su controlador es cuando está construyendo su modelo de datos para la aplicación. 
Si las pantallas con las que el usuario interactuará no se correlacionan con el modelo de datos de su aplicación, sus controladores probablemente tampoco deberían hacerlo.

ACCIONES Y RESULTADOS DE LA ACCIÓN

Después de asignar sus controladores, debe trabajar en las acciones que serán métodos en el controlador. Las hay en relación con el usuario y otras con relación al sistema

Debido a que existe un mapeo uno a uno entre las interacciones del usuario y las acciones en la aplicación, el conjunto inicial de acciones que debe crear debe ser claro si comprende el flujo de la aplicación.

Debería poder predecir la mayoría de las acciones según los requisitos de la aplicación

Es posible que tenga que agregar o modificar acciones más adelante. Descubrirá otras acciones que podrían no estar necesariamente vinculadas a una interacción del usuario, sino una interacción del sistema tomada por la aplicación en nombre del usuario. Los ejemplos incluyen un timer de JavaScript en el cliente que llama a una acción para obtener una actualización sobre el clima actual o rellenar listas desplegables basadas en una selección previa a medida que el usuario pasa por un formulario de entrada de datos.

Debido a que hay diferentes expectativas de una acción, existen diferentes tipos de resultados de acción.

ActionResult

Un resultado de acción es cualquier tipo de resultado de una acción. Aunque una acción tradicionalmente devuelve una vista o una vista parcial, también puede devolver resultados de JavaScript Object Notation (JSON) o datos binarios, o redirigir a otra acción, entre otras cosas.

Los resultados de ActionResult, dictan la experiencia del cliente!

Los nombres de las acciones también son importantes.

Como el nombre es parte de la solicitud de URL, debe ser breve y descriptivo.

  1. No sea tan descriptivo como para proporcionar demasiado del proceso comercial en el nombre, lo que puede ocasionar problemas de seguridad.
  2. También considere la coherencia de los nombres de acción en los controladores. Las acciones que hacen lo mismo con diferentes objetos deben tener el mismo nombre. La Convención también le pediría que no vuelva a utilizar el nombre del controlador en el nombre de la acción

VIEWS

La vista es la parte de la aplicación responsable de mostrar información a los usuarios. Es la única parte de la aplicación que los usuarios ven. Las impresiones iniciales de los usuarios y toda su interacción con su aplicación se realizan a través de una vista.

Puede establecer y leer valores como si la colección fuera un diccionario estándar: ViewData [«UserName»] = User. Nombre de usuario .

También puede acceder a los datos en el ViewBag como un contenedor: ViewBag.UserName = User.UserName .

Las siguientes son consideraciones adicionales cuando se trabaja con una vista:

  1. Vistas muy tipadas   Íntimamente se vincula el modelo de datos, haciendo uso de Razor (sintaxis que vincula C# con HTML)
  • Página principal o de diseño Una forma de compartir un diseño en varias páginas. Esto equivale a las Mater Pages.
  • Plantilla de Scarffold: Una plantilla que crea páginas estándar como parte del proceso cuando se crea un proyecto. Esta habilidad te da un inicio rápido en el desarrollo.

El lado del cliente o el lado del servidor

Elegir entre el procesamiento del lado del cliente y del servidor parece sencillo cuando observa las consideraciones de SoC.

El procesamiento del lado del cliente tiene más sentido cuando el trabajo que se realiza permanece completamente dentro del cliente, como cuando la selección de un valor en una lista desplegable cambia el color de fondo. Desafortunadamente, no encontrará muchos requisitos en los que la interacción sea completamente del lado del cliente.

Los factores a tener en cuenta al considerar el lado del cliente frente al lado del servidor son:

– El rendimiento de la aplicación

– La experiencia del usuario

– Los requisitos del negocio. 

El rendimiento de la aplicación es importante porque siempre habrá algo de latencia cuando se conecte a través de Internet.

La validación en el lado del cliente, por ejemplo, mejora el rendimiento eliminando las llamadas a través de la red para las transacciones que deben validarse.

Los sitios muy utilizados pueden aumentar el rendimiento bajando la carga del servidor. Sin embargo,

No sacrificar la seguridad por la velocidad. 

No debe reemplazar por completo la verificación del lado del servidor con la validación del lado del cliente. Con solo la validación del lado del cliente, todavía existe la posibilidad de que los datos incorrectos lleguen al servidor

Una buena práctica es poner la validación en ambos lados: en el lado del cliente para proporcionar una interfaz de usuario receptiva y reducir el costo de la red, y en el lado del servidor para actuar como una puerta de enlace para garantizar que los datos de entrada sean válidos.

Al considerar el procesamiento del lado del cliente y del servidor, recuerde que no es uno u otro; puede hacer ambas cosas en una sola solicitud de usuario. Además, es posible que algunas decisiones que tome del lado del cliente también deban replicarse en el lado del servidor.

Diseñando para la escalabilidad  1

¿QUÉ ES LA ESCALABIDALIDAD?

La escalabilidad es la capacidad de un sistema para manejar una cantidad creciente de trabajo.

Aunque el uso es mínimo durante el desarrollo del sitio, el uso puede aumentar mucho después de la implementación en un entorno de producción. Para garantizar una experiencia de usuario positiva, debe tener en cuenta la capacidad de escalamiento al inicio de la fase de planificación de la aplicación porque sus decisiones de escalabilidad afectan sus consideraciones de diseño arquitectónico.

Por supuesto, el ecosistema es finito. Esto es, la escalabilida tiene un límite. Los algorítmos o la arquitectura son finitos.

TIPOS DE ESCALAMIENTO

ESCALABILIDAD HORIZONTAL

Con la escala horizontal, puede escalar agregando nodos adicionales al sistema.

Este es un escenario de granja de servidores web, en el que se pueden agregar o eliminar varios sistemas a nivel de productos a medida que la demanda fluctúa. Se sirven utilizando un equilibrador de carga u otro equipo de red que determina a qué servidor se debe llamar.

La siguiente imagen muestra un arreglo de clusters por áreas organizacionales. El servidor «Controler» es asignado como el equilibrador de carga:

Aprendera los fundamentos teóricos de Web Farms en la lección «APLICACIONES DISTRIBUIDAS», más adelante.

LAS DECISIONES A TOMAR

Si su aplicación se escalará horizontalmente, debe tomar varias decisiones:

  1. Dependiendo del hardware de red que se implementará y cómo maneja las sesiones, la información de estado de su sesión se verá afectada.
  2. También debe determinar cómo afectarán los servidores múltiples al almacenamiento en caché de la información, por ejemplo, si se almacena en caché el HTML renderizado que se envió al cliente o los datos de caché de una base de datos.
  3. Si su aplicación proporcionará administración de archivos, considere dónde se almacenarán esos archivos para garantizar el acceso a través de múltiples servidores.
  4. La escala horizontal agrega algunas consideraciones de arquitectura, pero es una forma de escalación efectiva y de bajo costo, especialmente porque el costo para los servidores de productos básicos sigue bajando.
  5. Tenga en cuenta que los servidores básicos no son necesariamente servidores físicos, sino que pueden ser máquinas virtuales. Es mucho menos costoso acumular la capacidad no utilizada mediante la virtualización de otro sistema que agregar capacidad a un sistema.

Ventajas:

  • El crecimiento es prácticamente infinito, debido al incremento o adición de otros servidores.
  • Facilita el escalonamiento mixto (Vertical + Horizontal)
  • Permite y soporta la alta disponibilidad: Si un nodo falla, los demás sigue trabajando.
  • Soporta el balanceo de cargas.

Desventajas:

  • Exige un alto grado de mantenimiento.
  • Configuración compleja y extensa.
  • Las aplicaciones deben estar ajustadas al modelo de clusters.
  • La infraestructura debe ser robusta (Hardware)
  • Si el servidor primario falla, el sistema puede colapsar. Para esto se deben implementar servidores espejos

.

ESCALABILIDAD VERTICAL

Con la escalabilidad vertical, puede escalar agregando recursos a un solo sistema.

Esto generalmente implica:

  1. La adición de unidades de procesamiento central (CPU)
  2. La expansión de memoria principal.
  3. También puede referirse a acceder a más recursos existentes en el sistema.

La escala vertical también tiene sus propias consideraciones arquitectónicas. Una aplicación que se adapta a un solo sistema puede prestar más atención a los procesos de subprocesos, entrada / salida (E / S), recolección de basura y otras decisiones de diseño que ayuden a la aplicación a aprovechar mejor la memoria o CPU adicionales.

Una solución de escalabilidad vertical tiene también sus desventajas:

  1. Limitada. Teóricamente, puedes seguir agregando sistemas al escalar horizontalmente; sin embargo, es posible que se quede sin capacidad física en una solución vertical si el uso continúa creciendo.
  2. Además, la confiabilidad se ve afectada negativamente en una solución de escala vertical, ya que queda un solo punto de falla. Si la placa base del sistema se cae, también lo hace su aplicación.
  3. Escalabiliad de los datos: Por igual, debe considerar la escalabilidad de la base de datos al determinar sus métodos de acceso a los datos. Como desarrollador, no se espera que seas un arquitecto de bases de datos. Sin embargo, debe estar familiarizado con las posibles decisiones de base de datos y cómo pueden afectar su aplicación. Aunque muchas soluciones de escalabilidad para SQL Server no afectan su aplicación de conexión, algunas pueden hacerlo.

Para ilustrar de modo sencillo el último punto, durante el diseño de la base de datos, se puede afectar  la arquitectura del sistema debido a servidores separados almacenan datos diferentes por tipo de objeto. Puede darse el caso de que  existiese una base de datos para la gestión de estudiantes en el SERVIDOR-001, y otra para gestión de matrículas en el SERVIDOR-002, y cada una tiene un requisito de conexión diferente.

LA NUBE VS LA ESCALABILIDAD

Con respecto a la escalabilidad y las arquitecturas, considere los sistemas de alojamiento modernos basados ​​en la nube, como Windows Azure, para admitir sus requisitos de escalado.

Windows Azure proporciona escalabilidad inmediata y ofrece una función de autoescala que aumenta los recursos disponibles para su aplicación a medida que aumenta el uso.

Windows Azure también proporciona soluciones de almacenamiento de datos altamente escalables, tanto relacionales como NoSql. Si planea implementar una solución en la nube, debe asegurarse de que su diseño arquitectónico tenga esto en cuenta al abstraer la mayor cantidad posible de elementos que puedan cambiar.

Cuanto antes analice su necesidad de escalabilidad y comprenda cómo la administrará! Así, menos afectará a su aplicación.

CONMUTACIÓN POR ERROR

Un clúster de conmutación por error es un grupo de computadoras independientes que trabajan en conjunto para aumentar la disponibilidad y escalabilidad de los roles en clúster (anteriormente llamados servicios y aplicaciones en clúster). 


Los servidores agrupados (llamados nodos) están conectados por cables físicos y por software. Si uno o más de los nodos del clúster fallan, otros nodos comienzan a proporcionar servicio (un proceso conocido como conmutación por error). Además, las funciones agrupadas se supervisan de forma proactiva para verificar que funcionan correctamente. Si no están funcionando, se reinician o se mueven a otro nodo.

FAIL-OVER 1

Profundice el tema de Fail-Over Aquí..


* Fuentes: 

1. https://msdn.microsoft.com

 

Clic en "He completado este material" una vez lo finalices.