none
¿Dónde poner el BPEF en mi Sql2k14? RRS feed

  • Pregunta

  • Buenas a todos,

    Me gustaría definir un Buffer Pool Extension File para una de mis instalaciones en Always On que corre virtualizada por entero con Vmware

    Mi pregunta es, ¿dónde alojo el fichero, en qué LUN? Ese Always On corre contra Full Flash en lo que respecta a los MDF y la unidad de la TEMPBD.

    Si alojo este fichero dónde están los MDF.. ¿no habrá un coste de red hasta SQL para consumir los búferes?

    Y luego, al ser una máquina virtual si ocurre un failover del Always On, ¿cómo se recupera dicho fichero en el otro nodo o más bien cómo implementar que al ocurrir un failover el nodo secundario levante otro BPEF?

    Alguien me comentó definir ese fichero en el ESX lo cual me parece absurdo porque la propia máquina física no tiene SQL instalado...no tiene sentido.

    LA otra idea es definir el fichero en la propia C: virtualizada pero no hay espacio para ello.

    Gracias mil por vuestros comentarios,

    miércoles, 24 de agosto de 2016 12:09

Respuestas

  • Hola.

    Mi entendimiento es que deberías configurar el Buffer Pool Extension File en un SSD, para aprovechar las ventajas de éste, según Buffer Pool Extension.

    Ahora bien, si tienes una LUN asociada a un SSD, ahí debería estar configurado esto. Al ser una LUN y pertenecer al conjunto de discos disponibles para el Always On, no habría problema cuando pase un Failover, ya que la configuración se mantiene, tal cual como hace con las demás unidades.

    Para validar, ¿por qué quieres implementar esto? Yo he visto escenarios, no Always On o Failover Cluster, en donde han revisado esto, pero han decidido aumentar la RAM disponible...

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    • Marcado como respuesta Enric Vives jueves, 25 de agosto de 2016 16:24
    jueves, 25 de agosto de 2016 10:58
  • Hola.

    Entiendo la situación. Solo quería compartir la experiencia en un par de escenarios similares vividos, uno particularmente para que un Failover Cluster soportara una implementación ambiciosa con BizTalk Server.

    Sugiero, si se puede, que en ambiente de pruebas se haga la configuración para validar los beneficios que se obtienen con esto. En su momento, por ejemplo, hicimos un deck en el cual validábamos algunas transacciones y tiempos de respuesta sin el Buffer Pool Extension y luego con éste, para tratar de predecir que esto nos iba a funcionar tal cual lo esperado. Al final, y de nuevo, por las características de la implementación, se hicieron unos ajustes con TEMPDB e incrementos en RAM. Se que este no es el caso, pero de pronto te ayuda.

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    • Marcado como respuesta Enric Vives jueves, 25 de agosto de 2016 12:33
    jueves, 25 de agosto de 2016 12:24
  • Saludos

    Entonces mayor razón para que el hardware sea igual en el secundario, recuerda que algunas acciones como revision de integridad, y backups son tomados en el secundario no en el primario.

    Y si estas en sincrono y haces inferior el secundario el que la transacciones se sincronice tomara mas tiempo.

    • Marcado como respuesta Enric Vives jueves, 25 de agosto de 2016 16:24
    jueves, 25 de agosto de 2016 16:22

Todas las respuestas

  • Hola.

    Mi entendimiento es que deberías configurar el Buffer Pool Extension File en un SSD, para aprovechar las ventajas de éste, según Buffer Pool Extension.

    Ahora bien, si tienes una LUN asociada a un SSD, ahí debería estar configurado esto. Al ser una LUN y pertenecer al conjunto de discos disponibles para el Always On, no habría problema cuando pase un Failover, ya que la configuración se mantiene, tal cual como hace con las demás unidades.

    Para validar, ¿por qué quieres implementar esto? Yo he visto escenarios, no Always On o Failover Cluster, en donde han revisado esto, pero han decidido aumentar la RAM disponible...

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    • Marcado como respuesta Enric Vives jueves, 25 de agosto de 2016 16:24
    jueves, 25 de agosto de 2016 10:58
  • Gracias por tu respuesta Guillermo,

    Mi Always On está escaso de RAM, tiene que soportar 11 implementaciones de un ERP y está a punto de reventar y la opción de scale up no es opción en estos momentos. Budget is over

    • Editado Enric Vives jueves, 25 de agosto de 2016 11:57
    jueves, 25 de agosto de 2016 11:57
  • Hola.

    Entiendo la situación. Solo quería compartir la experiencia en un par de escenarios similares vividos, uno particularmente para que un Failover Cluster soportara una implementación ambiciosa con BizTalk Server.

    Sugiero, si se puede, que en ambiente de pruebas se haga la configuración para validar los beneficios que se obtienen con esto. En su momento, por ejemplo, hicimos un deck en el cual validábamos algunas transacciones y tiempos de respuesta sin el Buffer Pool Extension y luego con éste, para tratar de predecir que esto nos iba a funcionar tal cual lo esperado. Al final, y de nuevo, por las características de la implementación, se hicieron unos ajustes con TEMPDB e incrementos en RAM. Se que este no es el caso, pero de pronto te ayuda.

    Saludos,


    Guillermo Taylor F.
    MVP Data Platform & IT Pro
    Mi Blog

    • Marcado como respuesta Enric Vives jueves, 25 de agosto de 2016 12:33
    jueves, 25 de agosto de 2016 12:24
  • Sí, toda la razón. No es cuestión de ponerlo y pensar que va a ir mejor. El split de la TEMPDB la hize hace unas semanas.

    jueves, 25 de agosto de 2016 12:33
  • Saludos

    Bajo la moción normal es RAM es barato disco no lo es, comparativamente harás una menor inversion en discos que en RAM no veo el porque el budget te limita y compras lo mas caro y no lo mas barato, al ser un alwayson cada nodo debera de tener su propio storage asi que no existe realmente el failover de la LUN.

    El recurso debera de existir por nodo.

    tempdb y log files normalmente requieren el accesso mas rapido

    mdf y ndf el acceso mas lento

    Tempdb debe de ser o un disco flash nand v3 que tenga buen rendimiento en lecturas random, si es de primera generacion el flash es posible que un disco normal tenga mejor rendimiento que un disco de estado solido.  

    jueves, 25 de agosto de 2016 15:18
  • Enrique,

    ¿Quieres decir que el buffer pool extension file tendría que estar levantado al mismo tiempo en el nodo primario y en el secundario?

    Si se cae el primario en el failover entra el secundario y ya tiene el buffer pool extension file...pero, ¿para qué voy a tener el consumo de espacio de 2 Buffer Pool Extension File al mismo tiempo cuando no los necesito?

    También estoy pensando es en darle más memoria al primario que el secundario.

    ¿Qué os parece? Dado que el primario siempre es el mismo, ¿por qué asignarle la misma RAM al nodo sólo lectura?

    jueves, 25 de agosto de 2016 15:55
  • Saludos

    Contrario a FCI always on availability groups siempre esta activo y ambos nodos siempre deben de estar con hardware y software similar, puedes deshabilitar el buffer pool extension pero a mi juicio si lo haces seria en el primario no en el secundario, si vas a leer del secundario y no del primario el que debería de tener el buffer pool para lecturas seria el secundario no el primario, estamos de acuerdo?

    jueves, 25 de agosto de 2016 16:08
  • hummm.

    ¿Quieres decir que con FCI tenemos un Activo Pasivo y en Always On es A-A?

    Vamos a ver. No entiendo porque el secundario tiene que tener más potencia que el primario. Si las cadenas de conexión apuntan al listener y este tira contra el primario, ¿entonces?

    Lo que yo entiendo es que, el secundario "está arriba" para recibir todas las sincronizaciones pero las consultas se tiran contra el primero, ¿no?

    jueves, 25 de agosto de 2016 16:11
  • Saludos Enric

    Haber deja me explico lo mas normal al configurar un Availability group es que el primario solo reciva datos o cambios o sea inserciones y modificaciones, y leas todo del secundario.

    Si hacemos caso a esto los buffers cargan la información para un acceso mas rápido por lo cual es mas importante la carga en el buffer, esto considerando que esta es la implementation que estas haciendo si tu primario hará tanto lecturas como escrituras y solo tendrás el secundario como pasivo entonces puedes poner el buffer en el primario.

    No existe una receta de cocina sin modificación sino pautas de como hacerlo y ajustarlo a cada escenario que puedes tener.

    jueves, 25 de agosto de 2016 16:16
  • Vale, ya, entiendo.

    Mi Availability Group es síncrono con Failover automático.

    jueves, 25 de agosto de 2016 16:18
  • Saludos

    Entonces mayor razón para que el hardware sea igual en el secundario, recuerda que algunas acciones como revision de integridad, y backups son tomados en el secundario no en el primario.

    Y si estas en sincrono y haces inferior el secundario el que la transacciones se sincronice tomara mas tiempo.

    • Marcado como respuesta Enric Vives jueves, 25 de agosto de 2016 16:24
    jueves, 25 de agosto de 2016 16:22
  • Ok, muchas gracias
    jueves, 25 de agosto de 2016 16:24