Aprovechando la serie anterior de notas, y que ya tenemos un Failover Cluster montado y funcionando, esta vez vamos a aprovechar para crear un Servidor de Archivos de Alta y Continua Disponibilidad
Vamos a aprovechar una nueva e importante novedad en Windows Server 2012 Failover Cluster, como que ante la falla de uno de los nodos del Cluster, no se interrumpa el acceso a archivos compartidos. Y cuando digo “no se interrumpa” es que, por ejemplo, no se corte y haya que reinciar una copia de archivos :-)
Veamos primero una consideración muy importante a tener en cuenta: para que la funcionalidad nombrada pueda ser usada, en el disco se debe deshabilitar la generación de los nombres “8.3”
Por ser algo muy viejo quizás algunos ni lo conozcan :-)
En las viejas épocas de MS-DOS, los nombres de archivos no podían tener más de ocho caracteres para el nombre, más tres para la extensión. Esto era así, y punto
Una de las novedades que muchos le adjudican a Windows 95, pero que en realidad ya estaba presente en Windows NT 3.51, era la posiblidad de usar nombres de archivos largos, no limitados a “8+3”
Pero siempre estuvo el tema de compatibilidad hacia atrás, y así estamos, todavía generamos nombres compatibles con MS-DOS. Recién Windows Server 21012 propone un cambio
El hecho de cada vez que creamos un archivo se tenga que guardar con dos nombres diferentes, es algo que disminuye la performance de cualquier servidor y especialmente si es servidor de archivos
Hay una nota muy interesante sobre el tema en: Windows Server 2012 File Server Tip: Disable 8.3 Naming (and strip those short names too)
Hasta Windows Server 2008, por omisión, la generación de nombres 8.3 está habilitada, esto es, todo volumen que tuvo formato con este sistema operativo o anteriores, la tiene habilitada
Windows Server 2012, hace un poco de cambio, todos los volúmenes a los que se da formato, por omisión, tienen la característica deshabilitada, con una excepción el disco C:\
Podemos ver esto con el comando FSUTIL.EXE como se muestra a continuación
Por supuesto que es altamente conveniente deshabilitar la característica de generar los nombres 8.3, salvo que todavía tengamos aplicaciones que utilicen dicha nomenclatura.
Volvamos al tema que nos interesa, crear un servidor de archivos con continua disponibilidad :-)
Lo primero que debemos hacer, es en nuestro equipo SAN agregar un disco para dedicarselo a la funcionalidad de Servidor de Archivos (File Server)
Para eso en Server Manager, vamos a File and Storage Services \ iSCSI y procedemos a crear un nuevo disco
Pongan el nombre que le sea mejor, yo he puesto “FileDisk”
El tamaño que necesiten y pueda darle
Lo agregamos al Target existente
Ahora, en ambos nodos del Cluster, debemos ir a iSCSI Initiator, y conectar el disco. Yo lo haré de la siguiente forma (en ambos nodos)
Ahora en uno de los nodos (HYPER1) procederé a ponerlo Online, Inicializarlo y crear un volumen
Ahora toca ir al otro nodo (HYPER2) y ponerlo Online
Ya podemos agregar el disco a nuestro Failover Cluster siguiendo las siguientes pantallas
Algo a tener en cuenta, interesante, aunque no lo habilitaré en esta demo, es la posibilidad de habilitar Instantáneas de volumen (Shadow Copies) sobre el disco
Prosigamos … en ambos nodos debemos instalar la funcionalidad File Server, pongo sólo la siguiente captura de pantalla por si tienen dudas de dónde está, pero no pongo las restantes de cómo agregar el Role Service
Una vez que ha finalizado vamos a Failover Cluster Manager en cualquiera de los nodos y vamos a configurar el rol
Asignamos un nombre y dirección IP a nuestro File Server
Asignamos el disco
Observen que ha quedado como propietario HYPER2
Llegados a este punto, lo que debemos hacer es agregar una carpeta compartida que tendrá alta disponibilidad, siguiendo el asistente
Hoy esto poco creativo :-) la he llamado “Share”
Por omisión ya aparece marcada la opción “Continuous availability”
No nos preocupemos ahora por los permisos, la prueba la haré con Administrator que tiene control total sobre la carpeta
¿Comenzamos la prueba? En DC1 primero me conecto al sevidor de archivos del Cluster (\\HA-FileServer) y veo el compartido creado
Luego de abrir la carpeta Share, comienzo a copiar un “archivo grande” para que me dé tiempo a la demo (usé un install.wim)
Expandi en el cuadro de progreso “More details” para ver cuánto afectará
Y a mitad de la copia, a mover el rol de HYPER2 a HYPER1
Vuelvo a DC1 para ver cómo y cuanto se vio afectada la copia. Evidentemente muy poco
No satisfecho, mientras todavía esta copiando vuelvo a mover el rol a HYPER1
Todavía mejor
Algo importante a tener en cuenta de estas capturas: no saquen conclusiones de los anchos de banda, está todo hecho en máquinas virtuales, y como todos sabemos “siempre faltan recursos”
Notas Relacionadas:
Windows Server 2012: Failover Cluster para Hyper-V (Parte 1 – Creando la Infraestructura) | WindowServer: https://windowserver.wordpress.com/2012/11/22/windows-server-2012-failover-cluster-para-hyper-v-parte-1-creando-la-infraestructura-2/
Windows Server 2012: Failover Cluster para Hyper-V (Parte 2 – Configurando la SAN) | WindowServer: https://windowserver.wordpress.com/2012/11/22/windows-server-2012-failover-cluster-para-hyper-v-parte-2-configurando-la-san-test3/
Windows Server 2012: Failover Cluster para Hyper-V (Parte 3 – Configurando los iSCSI Initiators) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-3-configurando-los-iscsi-initiators/
Windows Server 2012: Failover Cluster para Hyper-V (Parte 4 – Instalando la funcionalidad Failover Cluster e Hyper-V) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-4-instalando-la-funcionalidad-failover-cluster-e-hyper-v/
Windows Server 2012: Failover Cluster para Hyper-V (Parte 5 – Creando y Configurando el Failover Cluster) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-5-creando-y-configurando-el-failover-cluster/
Windows Server 2012: Failover Cluster para Hyper-V (Parte 6 – Creando una Máquina Virtual con Alta Disponibilidad) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-6-creando-una-mquina-virtual-con-alta-disponibilidad/
WindowServer 
Comentarios
Excelente el artículo, pero en algunas pantallitas, faltaría un poco más de explicación. Un saludo desde Trujillo-Perú
Gracias por el comentario Juan Carlos, es un incentivo cuando se reciben comentarios
El problema de agregar explicación a algunas de las pantallas es que algunas darían casi para un libro :-) y esta nota ya está bastante larga
Básicamente lo que trato de hacer en el sitio es mostrar los «paso a paso» para una demostración simple que sirva como prueba de conecpto o desarrollo en un ambiente de pruebas, ya que para la implementación en productivo, en todos los casos habría muchas más consideraciones
En mi experiencia, tener un «laboratorio armado» funcionando me ha permitido, comprender y probar muchas cosas, y luego sobre las que tengo dudas o no comprendo muy bien cómo funciona poder hacer búsquedas bien orientadas
O diciéndolo de otra manera, proveer «la punta del hilo» para comenzar a tirar del mismo y llegar a donde necesitemos
Nuevamente, gracias por tu comentario
Gracias por tu excelente publicación, clara y detallada.
Es evidente que hay mucho trabajo previo que a veces no se valora.
¡Gracias Javier por el comentario!
Es verdad mucho trabajo, pero aunque no parezca así, hay demos «grandes» que van rápido y sin problemas, a veces las «chicas» o que parecen simples llevan horas de renegar :-)
Podrías aclararme que ventaja supone montar un servidor de archivos con disponibilidad continua, tal y como has hecho en un cluster; frente a dos servidores de ficheros con un sistema de ficheros distribuidos (DFS) replicando entre si, de modo que los usuarios del dominio se conecten al espacio de nombres DFS.
Más que ventajas, son cosas diferentes, cada uno tiene ventajas e inconvenientes
Un DFS con réplica se usa en general cuando necesitas acceso desde sitios geográficos diferentes, hay redundancia de datos ya que está replicados en más de un servidor, no se necesitan servidores dedicados ni que sean «casi iguales» ni que cumplan con «certified for Windows». Cada conexión trabaja sobre una de las copias y luego se sincronizarán (cuidado con los conflictos)
En cambio un «Failover Cluster» generalmente se hace con servidores en la misma red (ver aclaración al final), no hay redundancia de datos ya que todo está en el medio de almacenamiento compartido (aunque éste puede ser redundante), los servidores que son nodos de un «Failover Cluster» deben ser idénticos y dedicados a proveer los servicios «clusterizados», en general es una solución mucho más cara de implementar
Y muchas diferencias más, pero no quiero seguir extendiéndome ahora, que me vas hacer escribir una nota en los comentarios :-)
Aclaración sobre «Failover cluster». Se pueden crear en ambientes distribuidos, pero la complejidad es enorme y se necesitan soluciones de terceros para la replicación, ya que en ese caso no se comparte el almacenamiento
Si con tiempo te animas a escribir tus experiencias y reflexiones sobre «alta disponibilidad» para un árticulo, creo que puede ser interesante.
Por lo que he visto, la inversión y complejidad que exige montar un cluster, para almacenar ficheros (no para una base de datos) es muy superior a instalar dos servidores con DFS en la misma LAN; pero la funcionalidad conseguida es la misma.
En cualquier caso, gracias por publicar las pruebas que vas haciendo.
Hola Javier, respecto al tema funcionalidad, no cuidado que no es la misma y hay varias diferencias fundamentales
Para nombrar solamente alguna:
1a- Un DFS es sobre todo para ambientes distribuidos y no hay almacenamiento centralizado
1b- Un cluster es fundamentalmente para tener en un único sitio con almacenamiento centralizado. Aunque se pueden crear clusters en ambientes distribuidos la configuración y costo son enormes
2a- Un DFS es sólo compartir archivos
2b- Un cluster puede ser para compartir archivos, pero muchos servicios más. Acá vimos sólo máquinas virtuales
Y hay muchas diferencias más, pero dejo acá :-)
Hola amigos,
Tengo un problema… Voy a ser bien detallada porque la verdad no se donde puede estar el inconveniente!!
Hasta la semana pasada venia funcionando todo perfecto con una red con un servidor DELL Poweredge R310, 4 gb de RAM, 2 discos SAS de 10k de 500mb en raid 1.. con un Windows 2003 con 15 workstations con Windows 7.
El punto es que se quemo el mother del servidor y al no conseguir repuestos tuvimos que comprar de urgencia uno nuevo. En el pais no hay muchas opciones inmediatas por problemas con las importaciones… Compramos un HP GL 360 G8, 16gb de RAM, 2 discos SATA de 7200 de 1tb.
Instale un Windows 2012 STD 64bits en un raid 1 con los 2 discos SATA, configure el dominio, dns, active directory, usuarios ( todo lo habitual) y genere las carpetas compartidas con sus respectivos permisos. ( la funcion del servidor principalmente es servidor de archivos y hay una aplicacion de la empresa que se ejecuta desde los recursos compartidos, un exe de 4mb, nada muy pesado…).
El punto es que es IMPOSIBLE usar el servidor desde los clientes…. puedo acceder y navegar entre los recursos compartidos sin problemas… pero si quiero abrir un archivo de lo que sea en el servidor tarda una eternidad… por ejemplo 6 minutos para abrir un excel de 240 k. Si abro el ejecutable del sistema, veo en el administrador de tareas y veo que lo esta ejecutando y en uso de memoria esta 64k, al ratito cambia y va aumentando… hasta que llega al tamaño del archivo y finalmente lo abre… me tardo mas de 10 minutos… usar la aplicacion es casi imposible :( …
Desde el servidor ejecuto la aplicacion y va bien.. aunque no noto que vuele, funciona sin problemas.
En el servidor tengo armado un network bridge entre 2 placas de 1gb… la velocidad que me indica en detalles es 2gb. El switch de la red es gigabit, internet o si ejecuto recursos compartidos de otras pcs funcionan bien… No se que mas hacer…
Vi varias post e hice lo de
netsh int tcp set global autotuninglevel=disabled en el servidor y netsh int tcp set global autotuninglevel=highlyrestricted en las maquinas…
Deshabilite el antivirus, en el server y las pcs…
Deshabilite el firewall para las redes de dominio….
Estoy como desesperada… que puede ser? alguna sugerencia???
Desde ya mil gracias,
Saludos,
Hola Marlene,
Este no es un sitio de soporte, dejo abiertos los comentarios para que sean sobre la nota, y si puedo oriento en la respuesta a algún problema, pero por temas de extensión y datos necesarios no lo podemos utilizar para soporte
Respecto a lo que planteas, hago dos comentarios:
– Si el Dominio fue reinstalado (no recuperado de Backup), entonces es otro diferente aunque todo se llame igual. Internamente no utiliza nombres sino SIDs (IDs de seguridad, equivalentes a números de documentos). Se debe no sólo crear todo de nuevo, sino sacar las máquinas del Dominio y unirlas al nuevo, reasignar todos los grupos, permisos, etc. etc.
Siempre lo aconsejable es tener por lo menos dos Controladores de Dominio, para evitar lo que ha pasado. Inclusive este segundo Controlador de Dominio, si hay falta de presupuesto, se puede armar sobre un equipo no-servidor. Revisa el siguiente enlace y verás que es sencillo: https://windowserver.wordpress.com/2011/05/25/controladores-de-dominio-tolerancia-a-fallas/
– Por otro lado no puedes armar un «Bridge» con dos placas sobre la misma red pensando que con eso sumas el ancho de banda. Un Bridge conecta dos segmentos diferentes físicamente, por ejemplo Wireless y cableado
Otra cosa es crear un «NIC Teaming» que sí puede usarse como tolerante a fallas, o combinar ancho de banda
Tengo el mismo problema e igual de desesperado Marlene te agradecería mucho si encontraste la solución y puedas compartirla mi correo es maxxxxxx@hotmail.com saludos.
Hola Marco, la respuesta es la misma que le he dado a Marlene, no es este un sitio de soporte, no está relacionado el comentario con la nota, y además no agregas ningún dato más que pueda tomar para poder ayudarte
Si te sucede lo mismo luego de una *reinstalación* del Dominio, pues es lo esperado, aunque se llame igual es otro, porque internamente utiliza SIDs (Identificadores de Seguridad únicos)
O tienes más de un Controlador de Dominio para tolerancia a fallas, o recuperas de una copia de seguridad, o toca sacar todas las máquinas del viejo Dominio, pasarlas a grupo de trabajo, re-unirlas al nuevo Dominio, comenzar nuevamente con usuarios, grupos, permisos, etc. etc.
Hola Guillermo; primero que nada agradecerte por tu guía que me ha ayudado mucho. Está excelente, muy completa y detallada.
Mi consulta es la siguiente, a la configuración final me gustaría agregar un 4to equipo para crear un cluster con la SAN, para que en caso que el equipo caiga no se detenga el acceso a los VHDs allí alojados. Es esto posible?
Muchas gracias
Hola Federico, me alegro mucho te sirva la guía
Con respecto a la consulta de agregar otro servidor para tener tolerancia a fallas, yo he dado bastantes vueltas con el tema y no he encontrado una solución satisfactoria
Por un lado revisa la serie de notas que comienza con Hyper-V Cluster con Máquinas Virtuales en File Server Cluster – Demostración (Parte 1 Infraestructura Inicial) | WindowServer:
https://windowserver.wordpress.com/2013/08/06/hyper-v-cluster-con-mquinas-virtuales-en-file-server-cluster-demostracin-parte-1-infraestructura-inicial/ Es más que nada una prueba conceptual, Cluster de Hyper-V, accediendo a un Cluster de File Server, que toma los discos de un iSCI Target, que los toma por Storage Spaces
Le he dado muchas vueltas al tema tolerancia a fallas, y es mejorable lo hecho, por ejemplo para conectividad a la SAN usar NIC Teamings o múltiples placas con MPIO, pero no he conseguido tolerancia a fallas sobre el propio equipo (SAN), ya que es accedido por iSCSI, y aunque hay algún tutorial en Internet sobre armar un Cluster de iSCSI Target, el problema es que siempre hay que acceder a un medio compartido
Existen soluciones por hardware, en reemplazo del equipo SAN que proveen tolerancia a fallas, pero con Windows solamente no lo he podido lograr
Guillermo, muchas gracias por tu pronta respuesta.
Si, eh rondado varios tutoriales sin éxito. Los que lo logran siempre mueren en un punto débil que es un servidor extra que no tiene redundancia, y si cae cae todo. Después ya mandan a soluciones por hardware o softwares de 3eros
Lo que se me ocurrió es que el storage (sobre Windows) sea una VM y se replique a uno de los otros 2 HV. No es un FT pero es algo por si pasa lo peor
Seguiremos investigando y probando entonces… o a la espera de que Microsoft saque algo nuevo
Muchas gracias por tu tiempo
Si, como dices Federico, no es FT pero es una ayuda
cada rol que se agrega al cluster tiene que tener una ip diferente??
Hola nakatsue, cada rol que se va clusterizar, tiene que tener su propia dirección IP para poder accederlo
Robado de otros post :v copy-paste no es aporte
Hola elmaster, te puedo asegurar que no copiado de otro post, al contrario he visto algunas veces notas mías en otros lugares sin siquiera mencionar al autor
De todas formas ¿me puedes decir, según tu, de dónde he hecho copy/paste? porque me da que ha sido lo contrario
Magistral
Ja ja ja Gracias Pablo :)
Tu has creado el cluster sobre los servidores generales, pero se podría implementar sobre las máquinas virtuales directamente??
Todo lo que veas en este blog es sobre máqunias virtuales, y por supuesto el cluster
Lo que sí debes tener en cuenta, es que todo esto es sólo como demostración de configuración, para un ambiente productivo hay que asegurarse que las virtuales tengan alta disponibilidad
excelentes los tutoriales, en el ROL habrá forma de crear varios nombres a ese rol ya que lo he hecho por el DNS pero no muestra las carpetas compartidas
Hola Jorge, que yo sepa no se puede
Me alegro te sirvan las notas :)
Guillermo, porque no se uso un Clustered Shared Volume en esta demostracion? Esto haria que al fallar el nodo 1 se uso el disco 3 del otro nodo verdad?
Porque es W2012, no W2012R2, hay otra nota sobre esa configuración
Trackbacks
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File … […]
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibil… […]
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibil… […]
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibil… […]
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibil… […]
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibil… […]
[…] Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibil… […]
[…] han visto la nota “Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File …” podrán ver la diferencia en las registraciones del […]