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<[email protected]> escribió: > > 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. > -- Eduardo Arenas Castillo. +56 9 6629 1618
