Re: [pgsql-es-ayuda] Consideración para instalar postgresql en ambiente semi "virtualizado"

2014-04-06 1:05 GMT-03:00 Eduardo Arenas C. <edomax(at)gmail(dot)com>:

> Estimada comunidad,
>
> Escribo para consultar y apelar a vuestra experiencia sobre que cosas
> debería considerar para instalar postgresql en un ambiente entre comillas
> "virtualizado".
>
> Nos acaban de renovar la infraestructura de servidores, y tengo que migrar
> mi servidor de base de datos PostgreSQL, el cual esta instalado actualmente
> en un blade de las siguientes características: IBM blade server hs22 ,
> disco SAS 300GB en raid1, SO red hat 5.5 32 bit, potgresql 9.0.4 32 bit.
>
> Lo nuevo es un HP blade c7000, servidor proliant bl460c gen8 discos SAS
> raid1, parecido a lo anterior. Lo diferente es que obviamente subiremos el
> SO y postgresql a 64 bit y upgrade de versión.
>
> Y aquí vienen mis mayores dudas, ya que además esto estará conectado a un
> storage SAN HP MSA 2040.
>
> Mis dudas son:
>
> En un SAN ¿Correo el concepto de raid para la data de postgresql (raid10
> diferentes particiones)?. , pregunto esto por que la gente de arquitectura
> me dice que No... que el storage SAN tiene otra tecnología, me hablan del
> concepto de LUN, Virtual Connect, fiber chanell, la la la, en fin. Como que
> no sería necesario aplicar arreglos raid10, por que creo que el SAN es ya
> un arreglo de discos, me conviene seguir investigando? o estoy perdiendo el
> tiempo?
>
>
Un SAN no es otra cosa que un server con muchos discos e inteligencia
adicional que le permite usar features avanzados de storage (caché,
compresión, desduplicación, balanceo de IO, etc.). La preocupación de como
configuraron los discos del SAN es válida ya que aplica exactamente igual a
que si tuvieras los discos dedicados en tu server físico.
Dicho esto advierto que no se puede comparar SAN vs DAS (discos físicos en
el server) ya que en el SAN el entorno puede ser considerablemente más
complejo debido a la combinación de distintos tiers (arrays) de storage en
un mismo volumen sumado a que el IO es compartido entre varias
aplicaciones.

Para ejemplificar, es difícil determinar si un RAID 10 con 8 discos
exclusivos en el server de Postgres te brindará mejor performance que una
SAN con 48 discos en RAID 6, de los cuales 8 son SSD en RAID 10 que
trabajan de caché dentro del mismo volumen, compartida con una cantidad de
aplicaciones que vaya a saber que carga ejercen. Por lo general, si el
administrador de Storage no tiene ningún tipo de input pero cuenta con
suficientes discos, definirá al menos 2 o 3 volúmenes de distintos IOPS y
que terminará catalogando como lento, medio y rápido y luego negociará
contigo donde alojar tus filesystems. Con suerte el storage "rápido"
consistirá de una mayor proporción de discos en RAID 10 que de discos en
RAID 5 ó 6. Ojo, no conozco las capacidades del HP MSA y si soporta este
tipo de configuraciones y menos como decidió implementarlo tu storage
manager.

A la gente de storage les encanta que te presentes diciendo "mi sistema
requiere 1.2 IOPS", pero conozco muy pocas aplicaciones que tengan definida
esa unidad de performance de IO entre sus requerimientos de operación.
También es muy posible que si te dicen cuantos IOPS soporta el storage
logres entender que implicancias tiene eso para tu postgres.

Por último, lo más probable es que el storage ya está configurado de cierta
manera, hay montones de datos allí almacenados y hacer cualquier cambio a
nivel de configuración de los arrays requiere un esfuerzo considerable. En
definitiva, mi sugerencia es que no reniegues de antemano con como está
configurado el storage y en cambio hagas benchmarks por tu cuenta. Si con
ello resulta que el SAN no está a la altura de las circunstancias, ahí
puedes empezar a negociar para que o reestructuren los arrays o compren
discos adicionales y armen un RAID 10 exclusivo para la base.

Lo otro es que en la misma caja blade y compartiendo el mismo storage SAN,
> tendré diferentes ambientes producción, desarrollo, test, en fin me dicen
> que no afecta en nada por que todo es virtualmente independiente y muy
> potente... (los ambientes están en servidores blade no virtuales , es decir
> en otros hojas de la caja)
>
>
Esto es perfectamente normal. Lo que es recomendable es que los distintos
ambientes se alojen en Luns de capacidades diferentes. Por ej. Producción
en la rápida, Desa y Test en la lenta.
Yo virtualizaría todos los ambientes. Realmente difícil encontrar motivos
para no virtualizar el motor.

> Yo había cotizado algo con servidores independientes, pero el espacio y la
> escalabilidad de la plataforma primaron en la decisión de compra. No quiero
> hacer una instalación estándar y me gustaría aprovechar al máximo si puedo
> tener una mejora en rendimiento en la instalación.
>

> Que opinan ustedes?
>
>
Excelente decisión de virtualizar. A un pequeñísimo costo en performance
tendrán un montón de beneficios en la operación.

Saludos,
Fernando.