El cloud es seguro? Google vacía por error 150.000 cuentas de Gmail

Es el segundo caso en pocos días, primero hotmail y ahora Google.

Realmente como empresa, se puede confiar en el "cloud"?, personalmente yo no lo hago, ni pienso hacerlo, me gusta saber donde están mis datos y tener como mínimo una forma de recuperalos.

Nota sobre google en El País

Goole 0, empresas de Hosting 1

Como se dice, buscador a tus búsquedas....

 

Hola Ideas,

Si tienes razon, a mi tampoco me lleva mucho la atencion el cloud porque al final se vuelve un relajo saber donde esta cada cosa alojada, es mejor manejar tu informacion en tus servidores donde sabes en donde estan.

 

Estoy cansado del cloud en todos lados, cloud esto, cloud lo otro, todo el mundo lo vende como algo nuevo, cuando en realidad no deja de ser al fin y al cabo lo que llamamos Virtualización.

Respecto al tópico, prefiero tener mis datos e información en infraestructura propia.

 

No se puede generalizar por particularidades específicas. El cloud como tecnologia es seguro. El servicio que se ofrece sobre el cloud podrá ofrecer (o no) seguridad.
Y sea como sea, un raid1 no sustituye a un backup, estén donde estén los datos,

En realidad a pocos les importa dónde está almacenado su número de cuenta bancaria en su banco particular, o dónde está el registro de las llamadas de su móvil. Creo que el problema no es el medio sino el uso que se hace de él.

No se puede criminalizar una tecnología tan prometedora como el cloud por el uso que hacen unos u otros, sería como decir que el correo electrónico no es fiable porque hay quien envía virus o spam.

 

Sinceramente, no veo el cloud como una nueva técnología, es un simple sistema de virtulización, la seguridad siempre será dependiente de sus administradores y las características de los equipos que lo soportan, es decir tristes y sobrios servidores dedicados virtualizados con algún que otro sistema de almacenamiento de datos y no todos...

Te puedes montar "todo un cloud" con 4 servidores, así de simple...

Nuestro SDC (Virtualizado desde hace unos 5 años) tiene muchas mejores características, es mas seguro, estable y con mejor rendimiento como plataforma virtualizada que si la misma estructura la montamos como "cloud", apesar de que está compuesto por los mismos elementos de hardware.

Además de que un SDC virtualizado bien estructurado, tiene muchas menos probabilidades de fallo que montado como cloud y en caso de problemas las caídas son mucho menos graves y fáciles de solventar.

Los costos del cloud no son aceptables para el servicio de hosting compartido y no significan ninguna mejora para el dedicado o los VPS.

El cloud se diseño para ser utilizado por un solo cliente con necesidades de recursos muy altas, concretamente plataformas de investigación y cálculo, los cray eran un cloud hace muchos años, no para compartirlo y salvo muy raras (y caras) excepciones estamos delante de una nueva modalidad de sobrevender equipos y recursos bajo un nuevo concepto de márqueting.

El no tener una forma de acceder a tus datos de forma rápida y directa impide en el 99% de los casos hacer nada ante una caída seria, la duplicación no es parte del cloud, es parte de un buen diseño de SDC, si se muere un nodo en una plataforma virtualizada, incluso en el diseño más simple, puedes recuperar sus VPS inmediatamente en otro nodo, si se cae algo de la parte de control del cloud todo se cae y no puedes hacer absolutamente nada para solucionarlo, excepto esperar a que algún técnico de tu proveedor lo solucione.

La duplicidad de datos y la distribución de recursos no funciona ni con hosting estandar ni con DDBB, excepto si el diseño está especialmente preparado para ello, en hosting compartido, nada esta preparado para hacerlo, eso es igual para cloud que para cualquier otro sistema. Si quieres tener un nivel de alta disponibilidad en una DDBB, por ejemplo MySQl, debes hacerlo con replicas (esclavo) o con cluster, es exactamente lo mismo en cloud que en una plataforma virtualizada.

En mi opinión, el cloud es una nueva forma de vendernos una gran "máquina" en pedacitos muy pequeños que al final saturarán el proceso de I/O por bueno que sea, ejemplo VPS.net, tienen una muy buen infraestructura, duplicada, pero igual tienen problemas de I/O a cada rato.

Si consultas con cualquier ESPECIALISTA CON EXPERIENCIA te dirá que el cloud no es apto para procesos que tienen gran cantidad de I/O, como por ejemplo manejos de DDBB de millones de registros, porque es MUY lento.

Una de las principales ventajas del cloud es el poder "levantar instancias" que funcionen en paralelo cuando hay necesidad de atender un gran consumo de recursos, por ejemplo si hay muchas visitas a un sitio web, puedes levantar 10 o 30 procesos WWW en paralelo, la teoría es muy bonita, pero si hablamos de hosting estandar, con las aplicaciones y paneles de control que usa el 99% de los clientes, ninguna está preparada para utilizar esa técnica, es decir no se puede utilizar, para poder hacerlo necesitas que tu aplicación este diseñada para trabajar en una plataforma distribuida, con los recursos ordenados y segmentados, es decir para hosting compartido el cloud no significa ninguna diferencia sobre un VPS.

Es decir volvemos a los mismo, el cloud es aplicable para aplicaciones pensadas y diseñadas desde el principio para funcionar en el, el usar Plesk o cPanel en un cloud es tener un VPS en la nube, no tener una plataforma en cloud.

Espero dentro de poco publicar un artículo mas extenso sobre este tema y las implicancias que tiene el uso de estas tecnologías dentro del mundo del hosting compartido.

 

Como en todo, insisto, el cloud no es una solución de por sí, sino un medio técnico que te permite ofrecer una solución. Dado que el cloud no define una tecnología concreta, un determinado hardware o una topología de red, no se puede generalizar para decir si es válido o si es seguro, porque dependerá enteramente de la implementación que se haga y de la arquitectura a nivel de aplicación.

Por supuesto que cloud engloba virtualización, nadie dice que sea una nueva tecnología. Con virtualización y con cloud se pretende mininizar el impacto del fallo de hardware ofreciendo recursos no vinculados a un hardare sino a una capa intermedia. En este punto, el diseñador de la aplicación deberá saber si la pérdida de rendimiento le compensa en este punto o si un cluster de sql o de lustrefs se pueden acoplar como infraestructura de datos para ese cloud.

No voy a entrar en la eterna discusión de si es mejor o peor, porque cada solución tiene unos requisitos distintos y requiere de un diseño planificado. Sólo pretendo discutir el punto de que si un proveedor borra el correo, la culpa seadel cloud. En este caso concreto, la culpa será del manazas de turno o del responsable, pero no del concepto de tener los datos en un cloud.
¿Cómo era eso de que las ideas no matan a la gente?

 

Estoy de acuerdo contigo en que es una herramienta más que funcionará o no en función de para que y como la uses, mi comentario va directamente al uso del cloud para hosting compartido, pero te aseguro que el 99% de lo que leas y escuches sobre cloud te lo presentan como una nueva tecnología que es la panacea apara todas las empresas, es decir según la publicidad es la última cocacola en el desierto, heladita y con la chapita con premio...

 

En muchos casos (la mayoría) "cloud" no es más que una nueva forma de llamar a algo que existe desde hace mucho tiempo: un cluster de servidores con almacenamiento redundante distribuido en lugar de almacenamiento en discos locales.

Yo al "cluster" (voy a cambiar de palabreja) junto con virtualización (KVM, VMWare, XEN o lo que querais) le veo fundamentalmente 2 ventajas:

1.- Alta disponibilidad de hardware: si está bien hecho, si cae un equipo, otro asume la tarea del que ha caido. Sí, ya se que en teoría sólo con unas cuantas máquinas con virtuozzo y sin almacenamiento centralizado se puede hacer algo parecido, pero no sin downtime. Los que trabajais con servidores virtualizados con Virtuozzo (o Xen o VMware) ya sabeis lo que es mover copias de seguridad de varios cientos de GB de un nodo de backup a otro nodo de producción cuando te casca uno (por el motivo que sea).

2.- Rendimiento y flexibilidad (si lo dimensionas bien, claro).

En cuanto a los problemas de I/O que comentais, pues depende de cómo se estructure el "cluster". Haciéndolo bien, no tienes en absoluto esos problemas de I/O.

En cualquier caso. Montar un "cluster" de alta disponibilidad no es barato. No son 4 servidores y ya está. Empieza a sumar:

- Cabinas con discos SAS, niveles de RAID anidados y redundadas: no vaya a ser que una cabina se vaya a la mier... y te quedes en bolas.
- Servidores potentes (no uno ni dos ni tres) y con varias tarjetas de red
- Electrónica de red redundante (fibra a ser posible o cable direct attach si no tiene smás de 10 metros de distancia a salvar y a 10 Gbe).
- El software de administración y virtualización que quieras utilizar (con cuidado: hay soluciones que son una porquería).

Si pretendes montar todo eso en un sólo armario rack en un centro de datos, vete pensando en que no es la mejor idea. Mejor en varios armarios y al menos en salas separadas aunque saa dentro del mismo centro de datos, no vaya a ser que se te funda un armario entero y te vuelvas a quedar en "bolas". Redundancia es la palabra clave en toda esta historia.

Resumiendo: por menos de medio millón de euros no montas nada decente.

¿Que si esto sirve para hosting? Sirve de la misma forma que sirven los VPSs que se venden p.ej. bajo Virtuozzo. Sirve igual que un servidor dedicado. Insisto en el el I/O no es un problema en un cluster correctamente dimensionado. Claro que si lo que has hecho es ahorrar en cabinas o electrónica de red... acabarás con problemas sí o sí.

Luego sigo, que ahora tengo que ir a visitar a un cliente que quiere un cloud privado

 

Para redondear un poco el comentario y comprobar que el cloud, es tan inefectivo o más respecto a la integridad de los datos basta leer la explicación de Google:

.


http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html

 

Discrepo. ¿Que el cloud no es efectivo respecto a la integridad de los datos? También los de google dicen esto:

Es decir, un problema en su software borra el correo. El sistema de almacenamiento hace lo que tiene que hacer: replicar los cambios y así lo hace. Entiendo que el cloud ha hecho lo que se espera que hiciese.

Es como si le digo a mi mujer que tire una bolsa a la basura y luego me doy cuenta de que esa no era la bolsa. El problema no está (en esta ocasión) en mi mujer, que ha trabajado bien. No ha habido ningún problema en el funcionamiento de mi mujer, ha ejecutado la tarea solicitada. El problema esá en mi software, que le ha dado la orden equivocada.

Y con esta explicación más bien se apunta a todo lo contrario, que el fallo es humano, y por mucho cloud o lo que sea, el fallo humano es más poderoso y habría ocurrido de igual manera si el servidor de correo fuese un único servidor dedicado con discos locales: se habrían borrado igualmente los datos y habría que tirar de backup, ¿no?

 

Justo es a lo que me refiero, cuanto más grande es la infraestructura COMPARTIDA, más afecta un fallo, una caída, sea un error humano o de software, como en este caso que es precisamente lo que asusta, es mucho más dificil de manejar y necesita mucho más tiempo para solucionarse.

Los usuarios perdieron sus datos hace un tiempo considerable y todavía no saben ni cuando ni si los van a poder recuperar, cosa que el mismo Google lo pone como difícil...

En una infraestructura no "nubenizada" o simplemente virtualizada una recuperación de este tipo no tarda más de unas horas....

Precisamente el problema que tiene la "nube" es la complejidad de mantenimiento, la norma básica que hay que seguir en software y servicio el es KISS (Keep It Simple, Stupid)

Precisamente lo que no me gusta del servicio cloud es la complejidad del software y su administración, que lleva innato el aumento de posibilidades de error.

cincinnati, te aseguro que el I/O si es un verdadero problema cuando trabajas con miles de procesos en línea accediendo a mismo sistema de discos, aunque tengas un canal de 10Gb, si lo divides entre 10,000 procesos accediendo a la vez tienes un cuello de botella.

Es un simple problema de costos....

En cuanto lo de "si cae un equipo entra otro en funcionamiento" no es tan sencillo como parece, porque solamente funciona cuando el software que corre en ese sitio está preparado para hacerlo, es decir cuando hablamos de procesos distribuidos, si cae un server WWW, no pasa nada entra otro en su lugar, pero cuando la caida afecta a una estructura compleja, por ejemplo un server con panel de control y varios cientos de usuarios, la recuperación no es tan sencilla, porque se han perdido los estados y lo más probable es que el nuevo servicio levantado sea inconsistente, independientemente de que eso lo hace cualquier configuración de media disponibilidad, por ejemplo en Virtuozzo lo puedes hacer sin ningún problema con a partir de 3 nodos lee esto.

 

Creo que falta mucho aún para definir claramente que se entiende por "cloud".

Según "mi criterio" hago las siguientes clasificaciones :

VPS : Servidor virtualizado montado sobre un nodo de hardware.
Grid Server : Servidor virtualizado montado sobre un cluster de nodos de hardware con alta disponibilidad y redundancia de almacenamiento ya sea mediante una SAN o una replicación como lo hace Applogic.
Cloud Server : Servidor virtualizado montado sobre al menos 2 grid server independientes, idealmente localizados en 2 datacenters independientes para mayor redundancia.

Por lo tanto lo que la mayoría ofrece como cloud realmente no lo son y concuerdo con la mayoría de las opiniones anteriores en que solo serían lo que desde hace tiempo se conoce como Grid Servers.

Y respecto a los clouds propiamente tales además de la clasificación típica entre publicos, privados e hibridos, creo que hay que clasificarlos como en 3 grandes categorías de acuerdo a su tamaño, ya que la arquitectura, la tecnología, los costos, la tarificación, los servicios disponibles, la escalabilidad, mantenimiento, accesibilidad y la complejidad que tienen son bastante diferentes en la práctica :

Grandes : formados por miles de servidores como Google, Hotmail, Amazon, etc.
Medianos : formados por cientos de servidores como Rackspace, GoGrid, MediaTemple, etc.
Pequeños : formados por una menor cantidad de servidores y utilizando sistemas mas estandarizados como VMware, Citrix, Applogic, OnApp, etc.

El otro término que se tiende a mezclar con un cloud server es "cloud computing" que sería algo asi como un conjunto de servicios y recursos computacionales entregados sobre la web, a menudo "como un servicio" sobre internet ( IaaS, PaaS, SaaS ) y que en el fondo es el término que hoy se está tratando de "vender" asociado a lo que es "cloud".

En todo caso tenemos "cloud" para rato ... recuerdo cuando partieron los VPS y los subclasificaban como VPS, DDS, VDS, etc

ideasmultiples ... Me gustó el término KISS (Keep It Simple, Stupid), no lo había escuchado pero grafica muy bien lo que está pasando

 

creo que sin entrar en detalles ni hace falta tanto dinero para montar una estructura decente, y que todo sistema es fiable o no dependiendo de muchos factures en el caso del cloud la forma en la que este montada la estructura. Fallos puede haber en todos los sistemas, y luego estan por otro lado los fallos humanos claro esta.

saludos.

 

cloud? nunca me he fiado, y aunque a veces nos han propuesto probar esos servicios hemos optado por lo conocido y como dice fernando "Mejor es saber donde están los datos y tener como mínimo una forma de recuperalos"