2014-04-06 1:05 GMT-03:00 Eduardo Arenas C. <[email protected]>: > 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.
