none
ALWAYSON VS MIRRORING (Balanceo de Peticiones) RRS feed

  • Pregunta

  • Hola comunidad. Mi pregunta hoy es un poco, creo yo, tonta por mi ignorancia en el tema. Os comento un poco que es lo que quiero hacer y que he estado mirando.

    Vamos a actualizar nuestros servidores, hemos comprado 3 nuevos servidores en los que vamos a ejecutar SQL Server. La infraestructura se ha "planificado inicialmente" de la siguiente manera.

    2 Servidores estan juntos en una sala de servidores

    1 Servidor estara en otra oficina y se utlizara como BACKUP de la base de datos (segundo backup)

    Actualmente el sistema hardware es este

    1 Servidor SQL

    1 Servidor SQL (backup ofline, que ademas se utiliza como servidor de desarrollo)

    1 Servidor para las transacciones TCP

    En la nueva infraestructura, vamos a suprimir ese tercer servidor, ya que realmente realmente es un simple PC con Windows XP.

    El tema es que tenemos una aplicacion que hace transacciones online (en el servidor para transacciones TCP (windows XP)) con una aplicacion de cliente mediante un enlace TCP tipo chat, envia solo texto y el servidor realiza en nuestro servidor SQL las operaciones pertinentes. El tema es que ahora, hemos incluido en medio un servidor web que tambien ataca al servidor SQL, ademas de que en las oficinas tenemos un numero, cada vez mas creciente, de clientes con un software atacando al mismo servidor SQL.

    Bien, yo lo que quiero es:

    Incrementar la seguridad de la base de datos.

    Incrementar el rendimiento de la base de datos (balanceando cargas o transacciones)

    Para ello lo que he pensado es:

    Hacer un mirror, alwaison o replicacion de la base de datos del Servidor SQL1 al SQL2 que estan fisicamente juntos, con esto los datos los tendriamos siempre actualizados en los dos servidores, en caso de fallo del SQL1 podemos (aunque sea a mano) utlizar el SQL2 y los datos estarian actualizados. aralelamente, tal cual se hace ahora mismo, una vez al dia se haria la copia de seguridad en el servidor SQL3 (el que estara en otra oficina, y en el SQL2, aunque sea con otro nombre de base de datos, para fines de desarrollo). Con esto el punto 1 de la seguridad lo tendria solucionado.

    Y es aqui donde me vuelvo loco para conseguir mi segunda parte de mi nueva idea de implementacion de los nuevos servidores. Me gustaria que desde la pagina WEB atacara al SQL2 y asi liverar de carga el SQL1 que es el que ejecutara el servidor de transacciones TCP y dara servicio a los clientes por LAN de la aplicacion de cliente.

    En un principio no tengo problema de en la web hacer que ataque al SQL2, pero mi consulta es:

    Si los tengo en MIRRORING o en ALWAYSON (con replicacion ya se que no es posible) si hago una transaccion en el SQL2 tambien es reflejada en el SQL1??? porque si no es asi, inicialmente no me serviria esta solucion. Pero si es exactamente asi, entonces ya encontre mi solucion de "balanceo de cargas o peticiones" ya que, auque no es automatico, para lo que nosotros necesitamos es suficiente.

    Mi otra idea es, si tengo el MIRROR o el ALWAYSON desde la web podria hacer que las transacciones de solo lectura las enviara al SQL2 y las de escritura el SQL1, pero esto si que me complica un poco mas el tema de codigo en la WEB ya que tendria que controlar y cambiar, bastantes lineas de codigo.

    Para resumir un poco, que creo que me he liado mucho, lo que quiero es.

    Teniendo un MIRROR o un ALWAYSON se peude:

    1 Hacer cambios en el SQL2 y que se reflejen en SQL1?

    2 Con una REPLICACION es en tiempo real o cada cierto tiempo?

     Se comienza a instalar los servidores en 2 dias, y auque esto siempre seria posible hacerlo a posteriori, me gustaria hacerlo todo desde el principio, ya que seguramente, tendre que cambiar codigo en la pagina WEB.

    Gracias por adelantado. 

     


    DrUalcman


    • Editado Moderador M martes, 5 de septiembre de 2017 16:59 badword
    sábado, 2 de septiembre de 2017 2:04

Respuestas

  • En ALWAYSON todas las transacciones de copiado sobre el SQL2 son instantaneas, o hay algun retraso?

    Tienes dos opciones de configuración: puedes poner que el alwayson sea síncrono o asíncrono. Si lo pones síncrono, entonces la copia siempre es "instantánea" en el sentido de que mientras la transacción no haya sido grabada en los dos servidores, no te llega la respuesta al código cliente diciendo que se completó (en otras palabras, llamas a ese procedimiento almacenado que mencionas, y el procedimiento no retorna mientras sus grabaciones no se hayan confirmado en los dos servidores). Si usas el modo asíncrono, entonces la llamada regresa en cuanto la grabación se confirma en el servidor primario, y se pone en cola para enviarla al secundario. Esa cola pasará de forma casi instantánea al secundario, salvo bajo condiciones de muy fuerte carga de trabajo, en las que podría producirse un pequeño retraso. Hay herramientas de monitorización para conocer cuál es el estado de la cola y cuáles son los retrasos que se están produciendo, pero no puede configurarse un tiempo concreto.

    La recomendación sería montar SQL1 y SQL2 en el mismo centro de cálculo en modo síncrono, y luego montar un SQL3 remoto con modo asíncrono (para que no "frene" a los otros dos debido a la lentitud de las comunicaciones. Este SQL3 serviría como copia de seguridad permanentemente actualizada para caso de catástrofe en el CPD primario. Si quieres una base de datos para desarrollo en el SQL2 que esté premanentemete actualizada, puedes usar una réplica convencional (por ejemplo, transaccional, o incluso snapshot para las tablas que no sean muy grandes).

    domingo, 3 de septiembre de 2017 7:23

Todas las respuestas

  • Tanto con Mirroring como con Always On, solo es posible hacer transacciones de escritura en un único servidor (el que has llamado SQL1). Always On te permitiría enviar las de solo-lectura al SQL2, pero no se podría escribir en éste.

    La única modalidad que permitiría escribir a la vez en dos servidores y que las transacciones se repliquen sería una replicación transaccional peer-to-peer. Pero nótese que esta modalidad solo se soporta en la edición Enterprise de SQL Server, y que en caso de conflicto de replicación (que se modifique el mismo registro a la vez en los dos servidores) tendrías que tomar medidas para resolverlo, ya que la replicación transaccional por sí sola no sabe tratar esta situación.

    Es válida la solución que propones para el servidor web, en el sentido de que las transacciones de lectura-escritura vayan al SQL1 y las de solo-lectura vayan al SQL2, usando Always On. Puede que requiera menos cambios de los que supones, ya que si tienes razonablemente bien aisladas las partes que escriben y las que graban (por ejemplo, si usas el patrón repositorio y el repositorio tiene funciones separadas para leer y grabar), entonces basta con que dentro de las funciones abras dos conexiones distintas según sea para leer o grabar. En la conexión se añade un parámetro que indica las intenciones ("intent") de grabar o solo leer, y por dentro el cliente de Always-On las dirige consecuentemente al nodo que en ese momento está en condiciones de atenderlas (no necesariamente el 1 y el 2 respectivamente, ya que podría haber caído uno de ellos y ser necesario atenderlas desde el otro).


    sábado, 2 de septiembre de 2017 16:51
  • Gracias. Me queda claro que al final voy a tener que controlarlo un poco en codigo. casi el 95% de las operaciones se realizan con SP por lo que en codigo lo tengo facil todos los SP que se ejecuten en el SQL1 y los read en SQL2.

    Pero lo que no me termina de quedar claro es:

    En ALWAYSON todas las transacciones de copiado sobre el SQL2 son instantaneas, o hay algun retraso? Si lo hay se puede definir cuanto tiempo?

    Yo tenia pensado hacer, para el tema de seguridad.

    Replicacion basica, no PEER to PEER en SQL2
    Tal cual se hace ahroa mismo (muy pobre  a nivel seguridad) 1 Copia de segurar al dia tras el cierre de operaciones en SQL2 (esta copia es la que se usa para desarrollo, y hay veces que estar 1 dia atrasada es un problema)
    ALWAYSON por la posible caida de SQL1 que podamos tirar de SQL2.

    Muchas gracias


    DrUalcman

    domingo, 3 de septiembre de 2017 3:53
  • En ALWAYSON todas las transacciones de copiado sobre el SQL2 son instantaneas, o hay algun retraso?

    Tienes dos opciones de configuración: puedes poner que el alwayson sea síncrono o asíncrono. Si lo pones síncrono, entonces la copia siempre es "instantánea" en el sentido de que mientras la transacción no haya sido grabada en los dos servidores, no te llega la respuesta al código cliente diciendo que se completó (en otras palabras, llamas a ese procedimiento almacenado que mencionas, y el procedimiento no retorna mientras sus grabaciones no se hayan confirmado en los dos servidores). Si usas el modo asíncrono, entonces la llamada regresa en cuanto la grabación se confirma en el servidor primario, y se pone en cola para enviarla al secundario. Esa cola pasará de forma casi instantánea al secundario, salvo bajo condiciones de muy fuerte carga de trabajo, en las que podría producirse un pequeño retraso. Hay herramientas de monitorización para conocer cuál es el estado de la cola y cuáles son los retrasos que se están produciendo, pero no puede configurarse un tiempo concreto.

    La recomendación sería montar SQL1 y SQL2 en el mismo centro de cálculo en modo síncrono, y luego montar un SQL3 remoto con modo asíncrono (para que no "frene" a los otros dos debido a la lentitud de las comunicaciones. Este SQL3 serviría como copia de seguridad permanentemente actualizada para caso de catástrofe en el CPD primario. Si quieres una base de datos para desarrollo en el SQL2 que esté premanentemete actualizada, puedes usar una réplica convencional (por ejemplo, transaccional, o incluso snapshot para las tablas que no sean muy grandes).

    domingo, 3 de septiembre de 2017 7:23
  • Muchas gracias. Precisamente el SQL3 ya estaba previsto, pero la verdad que solo habia contemplado en este hacer la copia de seguridad diaria que se esta haciendo actualemtne, pero es buena idea tener tambien actualizado este con un ALWAYSON. EL SQL1 y 2, creo que lo comente, estan JUNTOS en el mismo CPD, y el SQL3 estara en una oficina remota.

    Creo que lo configurare siempre asincrono ya que realmente no es tan critico el trabajo, y para las operaciones de lectura de la web me llega, si tuviera un retraso de mas de 15 minutos pues tendria que poner sincrono, pero si es cuestion de segundos de diferencia no tengo gran problema.

    Y para el servidor de TCP necesito velocidad maxima en los SP ya que somos un mayorista de plantas que vendemos en subasta y el 90% de las transacciones son ONLINE con esa comunicacion tipo CHAT entre el servidor TCP y los clientes.

    Una vez mas gracias por aclararme las dudas.


    DrUalcman

    domingo, 3 de septiembre de 2017 7:55
  • Una cosa que me gustaría tocar... mencionas poco tiempo, una mala arquitectura llevada a cabo rapido y sin contemplar un crecimiento y demanda del servidor está destinada a tener mal desempeño.

    Ahora bien tienes que tener en cuenta muchas cosas como la versión de SQL Server y en especial que AlwaysOn es una característica enterprise y por lo tanto su costo es alto, en 2012 la replicación a secundario de modo síncrono estaba hasta cerca de 3 veces mas lenta que un servidor  standalone.

    También mencionas que lo quieres hacer como desarrollo, lo primero que me preguntaría es si es correcto que los desarrolladores tengan acceso a información de produtivo. Y mencionas que el servidor se usa para varias cosas esto puede tener un gran impacto en la lectura de la réplica (o en su defecto de la sincronización con el primario).

    lunes, 4 de septiembre de 2017 19:51
  • Gracias por la aclaracion que la replicacion es lenta, eso entonces tendre que probarlo un poco antes.

    Yo habia pensado en poner el SQL1 en lo que es el servidor y virtualizar el servidor WEB y el servidor ese TCP, que solo se utiliza desde las 18 horas hasta las 23 horas, y cuando esta en uso no se puede acceder a la WEB para hacer transacciones solo en modo lectura, eso ya es asi ahora mismo.

    El tema es que, aunque la empresa esta invirtiendo mucho dinero en esta actualizacion, vamos a comprar el enterprise de MSSQL, pero basicamente por la cantidad de nucleos que tienen los servidores que son mas de 24 y es la unica version que nos es valida, vamos a pasar de tener 3 servidores a solo 2. Pero uno de los 3 servidores, el que tiene ahora mismo ese servidor TCP es un simple Windows XP, ya os comento que es una simple aplicacion de escritorio.

    Como comentaba, pensaba virtualizar el servidor WEB, y el TCP, y que lo que es el servidor sin virtualizar el que va a soportar el SQL Server. Eso en los SQL1 y 2 que estan juntos en el mismo CPD, en el que va a estar remoto, solo tendra esa copia de seguridad tras el cierre del dia (que es a las 8 de la mañana) tal cual se hace ahora, pero estaria preparado para, si es necesrario por desastre sumo, lllevarlo a la empresa y que tomara el control.

    La copia, ahora mismo, se hace una vez al dia en el SQL2 (para no liaros mucho) y es con la que trabajamos para desarrollo. Inicialmente eso no lo quiero cambiar, para desarrollo trabajariamos igual, son una copia de la base de datos del dia de ayer, pero me gustaria esa PRIMERA copia online, para que los datos esten mas actualizados y no perder un dia entero de transacciones que es el riesgo que tiene la empresa ahora mismo.

    Ya lo comente con mi jefe y le ha gustado mi idea en la nueva infraestructura.

    El SQL2 sera el servidor de archivos tambien, no tenemos mas necesidades en la empresa por ahora.

    Muchas gracias por tus aclaraciones y se las comentare a mi jefe hoy mismo.


    DrUalcman

    • Propuesto como respuesta Enrique AA lunes, 4 de septiembre de 2017 20:39
    • Votado como útil Enrique AA lunes, 4 de septiembre de 2017 20:39
    lunes, 4 de septiembre de 2017 20:35
  • Disculpa esto me borro lo que habia puesto.

    En versiones mas nuevas el tiempo de la sincronización ha bajado considerablemente no recuerdo bien el valor pero andaba entre 1.3 a 1.5 veces el tiempo normal, a menos que alguien tenga un dato mas reciente. Yo vería mejor virtualizar en estos servidores en vez de meter todo en la misma caja para tener un mejor control de los recursos.

    lunes, 4 de septiembre de 2017 20:47
  • 1.3 a 1.5 segungos? minutos? horas? si es lo primero, no tenemos mayor problema, si es lo segundo o tercero ya me supondria un problema, y esto es solo en replicacion o en ALWAYSON?

    Como ya comente, al ver el tema de virtualizacion, que es la primera vez que puedo probarlo, me ha gustado mucho, pero sobre todo para el servidor WEB y ese TCP para las transacciones por chat.

    Gracias una vez mas.


    DrUalcman

    lunes, 4 de septiembre de 2017 21:09
  • Saludos

    1.3 veces el tiempo que tomaria en un stanalone.

    lunes, 4 de septiembre de 2017 21:10