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

Ernesto y Fernando,

gracias por los tips y aclaraciones, la verdad es que esta bastante buena
la info. He leído otras cosas , creo que no me queda mas hacer pruebas de
IO y si la cosa es aceptable, quedarme con la configuración por defecto,
sino intentar negociar.

Saludos y gracias

El 7 de abril de 2014, 16:07, Fernando Hevia<fhevia(at)gmail(dot)com> escribió:

>
> 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.
>

--
Eduardo Arenas Castillo.
+56 9 6629 1618