"Ademas no puedes levantar servidores en demanda, primero los creas y
configuras y luego los usas, de manera permanente en lugar de instanciar
imagenes." uh? porque no? pensé que todo el punto de la virtualización,
chef y todo eso era poder levantar servidores y configurarlos
automaticamente al vuelo.
PD: en el HG tendremos algunos cursos de esos en la brandnew comunidad de
devops para quien guste acercarse y así.
2013/9/2 Jorge Gabriel Lopez Paramount <jorge.lopez.paramo...@googlemail.com
> Que tal?
>
> Ese es uno de los problemas que le veo a las palabras de moda: alguien las
> invento, y en el mejor de los casos fue especifico y la gente fue haciendo
> el significado mas amplio, y en el peor nunca intento definir algo
> concreto, como esto de la nube.
>
> Yo le veo tres significados: el primero, tener acceso a informacion y
> quizas aplicaciones desde donde sea, en cualquier dispositivo, algo
> privado
> como ownCloud o publico como Google. No tiene nada de esoterico,
> simplemente un sistema web que te permite ver y compartir archivos en
> cualquier dispositivo.
>
> El segundo, infraestructura como servicio, o sea algo privado como
> openstack o publico como amazon, que el uso mas sencillo es lanzar
> servidores de apache en demanda. El problema que le veo es que en amazon
> tiene sentido si no te preocupa la privacidad, pero en tu nube privada ya
> compraste los servidores asi que los tienes que usar para algo mas que
> esperar picos de carga de paginas web.
>
> Y el tercero, todo lo que este en red, sea algo como salesforce o tan
> cutre y viejo como un servidor de ftp.
>
> Por ejemplo yo uso mucho los servidores virtuales y entiendo las ventajas
> de tener muchos en una misma computadora, es excelente, pero para mi no es
> una nube, la virtualizacion ya es vieja y estaba antes. Ademas no puedes
> levantar servidores en demanda, primero los creas y configuras y luego los
> usas, de manera permanente en lugar de instanciar imagenes. Openstack es
> mas nuevo y si bien esta basado en la virtualizacion, para mi es
> suficientemente diferente para ponerlo en categoria de nube.
>
> En resumen: la virtualizacion es excelente no importa el tamano de la
> operacion, openstack es matar mosquitos a canonazos para la gran mayoria
> de
> las empresas. :-)
>
> Saludos,
> Jorge.
>
> Gabriel Orozco <redim...@gmail.com> wrote:
> >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.
