Es que al parecer el chronosh esta transportando su "expertice" de su vaporcloud a "la cloud"... y no tiene nada automatizado. No es cloud si no esta automatizado, no es solo "deploy", es la automatización lo que hace "cloud" al "cloud"...
On Tuesday, September 03, 2013 12:26:42 PM Levhita wrote: > "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.
