De hecho, tienes razón respecto de la base de datos. lo que hay alli es
un montón de bases de datos y el Oracle responde según la carga.
Por lo tanto, si tienes tu Oracle en una buena configuración de alta
disponibilidad, yo no lo movería a máquinas virtuales.
Ejemplo: los días de nómina Peoplesoft se lleva la mayor carga de la
base de datos. Los días posteriores la tienda web y el sistema de B2B
(Bussiness to Bussiness), y B2C todo el tiempo, solo sube en épocas de
ofertas y los fines de semana largos, por ejemplo.
El mismo RAC de Oracle puede manejar las cargas mientras no sea todo al
mismo tiempo.
Ahora bien, que pasa si tienes una aplicación que escala
horizontalmente? (apache me viene a la mente, no es tan dificil como
comentas, y menos con herramientas como Cheff y similares, otras
aplicaciones en Java tambien)
Ahora aparte haz un sobre-alojamiento: pon máquinas virtuales que
estando todas a su pico de eficiencia, usen, digamos, 150% de la
capacidad del servidor. El asunto es que como *no todas* usan su pico de
eficiencia al mismo tiempo, el servidor nunca pasa del 90-95% de
utilización. y si pasa, simplemente mueves la máquina virtual a otro
server... sin apagarla, en vivo...
No te digo que tenemos *todos* los tipos de virtualización que aqui
comento, pero en nuestra nube privada si los tenemos, y por ejemplo el
poder tener un servidor virtual en cuestion de minutos para un nuevo
proyecto, es una verdadera ventaja competitiva. Nuestra nube virtual nos
lo permite.
El mes pasado estuve instalando aplicaciones en máquinas virtuales que
se nos otorgaron en la nube privada. Estoy seguro que todas las
eficiencias están contempladas y si necesitamos más poder en algún
server será cosa de mandar un request y que nos suban la capacidad
garantizada. Simple, eficiente, rápido.
No todas las cargas y no todas las aplicaciones pueden usar una nube
privada, pero hay unas que este tipo de solución les vino a ayudar bastante.
Saludos
Gabriel Orozco (Redimido)
El 13-09-01 09:54 PM, Jorge Gabriel Lopez Paramount escribió:
Que tal?
Yo estoy de acuerdo que con maquinas virtuales y una buena planeacion de
tiempos puedes hacer eso, pero hasta donde entendi openstack no es necesario,
es mas, en una empresa tipica la necesidad de recursos humanos y materiales
extra no los vale, y podria no adaptarse a ello.
Como de que tipo de aplicaciones que requieren mucho poder de computo estamos
hablando? Como una nomina que se calcula cada mes por ejemplo? Siendo mas
concretos, una aplicacion propietaria como Peoplesoft?
Pongamos un caso asi. Para empezar, aun si Peoplesoft solo requiere mucho poder
de computo dos veces al mes eso no significa que pueda estar abajo el resto del
mes. O sea, de entrada no puedes levantar, dar de baja y volver a levantar
bases de datos en demanda que es el objetivo de openstack.
Pero supongamos que usas un RAC de Oracle para Peoplesoft, y otro para otras
aplicaciones, y quieres que los dias de quincena casi todos los nodos esten en
el cluster de peoplesoft y el resto corra las otras aplicaciones. Se oye
practico y eficiente, no?
Pues si, es posible en teoria, pero en la practica recomisionar nodos de Oracle
no es asi de facil, requiere de una configuracion compleja y DBAs de primera. Y
estamos hablando de nodos normales, virtuales o reales, todavia no entra
openstack. Yo se que es posible pero no me ha tocado verlo nunca.
Ahora, supongamos que la empresa es tan grande que la nomina corre en un RAC de
unos 20 nodos. Alguien se tomaria el trabajo de contratar un par de DBA de
50,000 al mes para recomisionar un par de nodos de un rac a otro?
Entonces ya entra openstack, precisamente para este tipo de cosas es. Pero no
sucede magicamente, si es dificil configurar nodos de un rac para que se pasen
de un cluster a otro, todavia mas dificil es lograr que una imagen unica sirva
y sea adaptable para los 20 nodos que piensas usar. Porque si piensas tener 20
imagenes distintas, una para cada nodo, entonces no necesitas openstack.
Y como resulta que las imagenes son transitorias en escencia, el almacenamiento
se complica, ya no digamos el de las bases de datos, incluso los logs tienen
que guardarse en algun lado.
Y este me parece un caso sencillo, estamos hablando de pasar nodos de bases de
datos de un cluster a otro. Que pasa si lo que en realidad quieres es dar de
baja nodos de Oracle para levantar servidores de Apache? Vas a necesitar DBA de
primera y sysadmin de primera, entonces ya llevas por lo menos 200,000 de
nomina al mes.
De las empresas que he conocido solo la firma de Wall Street que mencione me
parece que podria hacer algo asi. Estoy hablando de miles de servidores
virtuales, y no para toda la firma, es solo para un area. Y servidores que ya
estan pensados y configurados de antemano para correr 2 o 200 en paralelo, no
es simplemente levantarlos y ya.
Yo todavia estoy por conocer personalmente una empresa que corra y aproveche
una nube privada de openstack. Para correr servidores apache en demanda es
suficiente y quizas mejor Amazon, no hay necesidad de fletarse toda la teoria
de openstack.
Saludos,
Jorge.
"Gabriel Orozco (Redimido)" <redim...@glo.org.mx> wrote:
hola, llego tarde al thread, pero les dejo un comentario:
No se trata de tener *una* aplicación corriendo en OpenStack.
Visualicen una empresa donde unas aplicaciones requieren mucho hardware,
pero no todo el tiempo. y hay otras que lo mismo, tampoco todo el tiempo
pero requieren mucha galleta.
Con una nube de OpenStack y una planeación de tiempos puedes lograr lo
que te costaría 4-5 veces más. solo por el hecho de poder balancear la
capacidad disponible.
Como todo, requiere que tus aplicaciones estén diseñadas para soportar
escalabilidad horizontal
Saludos
Gabriel Orozco (Redimido)
OpenStack affiliate (sepa que será eso)
El 13-09-01 08:09 PM, Jorge Gabriel Lopez Paramount escribió:
Eso se oye muy bien, pero para eso no necesitas openstack, basta con aprender
como funciona la nube de Amazon o el proveedor que quieras, y por lo menos para
Amazon puedes practicar con pequenas maquinas practicamente gratis. No hay
necesidad de quebrarse la cabeza configurando openstack y comprando servidores,
con el poder de tu firma y muy poca teoria puedes empezar.
De que te sirve reducir el numero de instancias en servidores fisicos de tu
empresa si de todas formas ya pagaste por el hardware? Una nube privada de
openstack asi funcionaria, no?
En el cliente que mencione de Wall Street tenian cargas variadas, lo unico
seguro era que necesitaban todos los servidores de que disponian. Lo que
cambiaba era como iban a distribuir el poder de computo que tenian, y la
distribucion entre areas podia cambiar de un dia para otro, incluso a veces en
cuestion de horas cambiaba.
Como ya lo dije ellos no usaban openstack sino un sistema desarrollado en la
empresa, y los nodos eran basicamente de procesamiento (CPU), ahi se corrian de
forma distribuida los algoritmos para hacer calculos financieros. Dependiendo
de la cantidad de portafolios a calcular y de su complejidad era la cantidad de
maquinas virtuales que asignaban.
Por que no usaban hardware directamente en lugar de virtualizar con la carga
extra que implica? Porque habia proyectos tan pequenos que una maquina completa
hubiera sido demasiado, y algunas veces los programas se trababan o el servidor
se cargaba tanto que habia que reiniciarlo. Y reiniciar un servidor donde los
calculos toman 10 minutos no es problematico, pero reiniciar uno donde los
calculos toman 10 horas solo porque otro proceso se trabo no es admisible. Sin
mencionar que estaban organizados en clusters y si un nodo fallaba las maquinas
virtuales simplemente se migraban.
Para esto si vale la pena estudiar e implementar openstack, pero si tienes un sitio en la
red y no quieres que acabe "slashdotted" con ponerlo en Amazon es suficiente.
Saludos,
Jorge.