El nuevo incendio de OVH en Estrasburgo habría afectado a 300 baterías de 25 kg en el edificio SBG1. Los bomberos lo extinguieron con una lanza de espuma. Luego procedieron a la ventilación del cajón e hicieron un reconocimiento en los cajones vecinos. Dos empleados sufrieron ligeras molestias por los humos. Se llevó a cabo un examen sobre ellos en el lugar de lo ocurrido.
#20:
#4 Por eso las regiones de AWS tienen al menos tres AZ, con una separacion significativa (AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other) Y cada AZ suele tener mas de un data center independiente. Lo mismo para GPC. Desafortunadamente Azure no sigue estas practicas
#43:
#29 Visto el ritmo de incendios que llevan, sí, es corriente y es continuo
#28:
#24 Si un asteroide destruye un radio de 100km quizá la pérdida de datos resulte un problema menor.
PD: La nube es el PC de otro y se puede quemar, no es un lugar mágico donde los datos duermen plácidos toda la eternidad como piensan muchos.
OVH esta cubriendo un nicho de negocio, de muy bajo coste y servicios minimos.
Y la responsabilidad (backup, plan de recuperacion,...) recae en quien lo contrata.
#45:
#28 [abuelo cebolleta]
Estaba seleccionando fotos de centros de datos para una publicación cuando una compañera las ve y me pregunta que es eso, le contesto que un centro de datos, donde están los discos duros de las nubes y ella dijo "¿discos duros? ¿la nube no es algo más virtual?"
[/abuelo cebolleta]
#74 gracias por la información. No tengo claro la razón, pero en muchos medios aseguran lo contrario. Será copia y pega de un medio francés sin verificar.
#77 Ya, también lo leí en varios medios sobre que era "uno de los más grandes" y solo con ver una foto del edificio del SBG1 pensé "ni de coña"...
Imagino que en su día habría sido uno de los más grandes de Europa, pero cada año se construyen decenas de data centers masivos por todo el mundo, mucho más grandes que ese.
#28 [abuelo cebolleta]
Estaba seleccionando fotos de centros de datos para una publicación cuando una compañera las ve y me pregunta que es eso, le contesto que un centro de datos, donde están los discos duros de las nubes y ella dijo "¿discos duros? ¿la nube no es algo más virtual?"
[/abuelo cebolleta]
#45 Claro, los datos se almacenan en el emprendimiento de Jeff Bezos, que ha abandonado su cuerpo convertiéndose en un ente todopoderoso fusionado a Internet.
#28 Eso no sé, pero muchos se pensaban que tener los datos “en el cloud” implicaba automáticamente redundancia a prueba de bombas gestionada por el proveedor al mínimo precio y ahora se han llevado una ostia de realidad
Me cago en la leche. He vuelto a tener un micro infarto. Tengo los servidores en GRA1. Esto ya es tremendamente sospechoso. Voy a tener que plantear tener unos servidores espejo en Amazon. 😤
#40 Yo tengo programados backups diarios, pero luego, realmente, los saco cada 1 o 2 semanas. Antes tenía automatizado el envío de los backups a otro servidor, pero al final los quité y empecé a bajarme a mano aquellos backups que considero más importantes (evidentemente, casa 1 o 2 semanas). Hay que decir que el servidor de backups lo tenía en el mismo sitio, así que, ante una catástrofe así, estaría igualmente jodido.
La cosa es que, ahora mismo, uno de los servicios que estoy dando NO se puede parar y perder dos semanas de datos ya sería catastrófico.
Debería volverme más desconfiado/precavido con los años, pero parece que cada vez soy más confiado. Hasta que tenga un buen susto. 😑
Debe ser que el mantenimiento debe ser muy cutre. Todas las librerías de almacenamiento tiene alarmas sobre sus sais y fuentes de alimentación con baterías hasta el más cutre lo tiene, y si no le haces caso en muchos casos se apaga el equipo. Pero si esta ahí mucho tiempo el sello se rompe y gotea y produce cortos o hasta fuegos. Esta en todos los manuales. Increíble.
#58 Yo en el último año he recibido tres alertas por incendio de DCs en los que teníamos servicios desplegados. La receta es muy sencilla:
- Se diseña la sala.
- Se pone en producción.
- Se meten unos cuantos racks a mayores porque bien caben y no hay dónde meterlos,
- Se baja un poco la potencia del clima porque este mes ha subido mucho la luz.
- Un par de horas en el horno... y listo para servir no servir
#71 y te faltó las subcontrata, que no tene recursos para atender avisos porque no tiene herramientas. Dígase vehículos, móviles, baterías, discos duros y sigo.....
#72 La verdad es que en DCs no he visto mucha subcontrata, no les debe de dar para tanto. Pero en uno de esos avisos nos decían que sus ténicos estaban solucionando el problema, así que me imagino que además del currículum de sistemas pedirán 5 años de experiencia como bombero
#24 Las múltiples zonas son un primer nivel, si de verdad te preocupa que esten tan "cerca" puedes usar múltiples regiones y distribuirlo por todo el planeta, pagándolo eso sí, pero vamos que él que realmente lo necesita tiene la opción.
#4 Por eso las regiones de AWS tienen al menos tres AZ, con una separacion significativa (AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other) Y cada AZ suele tener mas de un data center independiente. Lo mismo para GPC. Desafortunadamente Azure no sigue estas practicas
OVH esta cubriendo un nicho de negocio, de muy bajo coste y servicios minimos.
Y la responsabilidad (backup, plan de recuperacion,...) recae en quien lo contrata.
#27 Precisamente yo tengo un par de servidores en OVH que si se queman de da igual, los uso para integración continua, despliegues de prueba y hostear alguna que otra tontería. Los puedo sustituir inmediatamente. OVH mola porque es baratillo para estas cosas.
#20 Lo que no te suelen decir destacar mucho cuando se diseña un plan de alta redundancia es que el tráfico dentro de la misma región entre distintas AZ te lo cobran como si fuera entre dos regiones. Luego se monta un proyecto de big data de alta redundancia, miran la factura y flipan
#51 Tampoco te destacan que el trafico entre AZs se cobra en ambas direcciones ("in and out") asi que cuando ponen en letra muy pequeña, que en trafico entre AZs es de $0.01/GB en realidad es de $0.01/GB (de salida de la AZ de origin) + $0.01/GB (de entrada en la AZ de destino) === $0.02/GB "
Calcular lo que va a costar algo en AWS (o en Azure, o GPC) es mision imposible.
Comentarios
Tanto incendio ya huele a chamusquina
#29 Visto el ritmo de incendios que llevan, sí, es corriente y es continuo
Esta gente lleva el chaos engineering a otro nivel
#3 No estaba ni entre el top #10 europeo
http://worldstopdatacenters.com/biggest-by-region/aema-size-rankings/
#74 El SBG1 era de 1 MW (según acabo de Googlear) y el 10º de esa lista tiene más de 9 MW de potencia máxima.
#74 gracias por la información. No tengo claro la razón, pero en muchos medios aseguran lo contrario. Será copia y pega de un medio francés sin verificar.
#77 Ya, también lo leí en varios medios sobre que era "uno de los más grandes" y solo con ver una foto del edificio del SBG1 pensé "ni de coña"...
Imagino que en su día habría sido uno de los más grandes de Europa, pero cada año se construyen decenas de data centers masivos por todo el mundo, mucho más grandes que ese.
#24 Si un asteroide destruye un radio de 100km quizá la pérdida de datos resulte un problema menor.
PD: La nube es el PC de otro y se puede quemar, no es un lugar mágico donde los datos duermen plácidos toda la eternidad como piensan muchos.
#28 [abuelo cebolleta]
Estaba seleccionando fotos de centros de datos para una publicación cuando una compañera las ve y me pregunta que es eso, le contesto que un centro de datos, donde están los discos duros de las nubes y ella dijo "¿discos duros? ¿la nube no es algo más virtual?"
[/abuelo cebolleta]
#45 Claro, los datos se almacenan en el emprendimiento de Jeff Bezos, que ha abandonado su cuerpo convertiéndose en un ente todopoderoso fusionado a Internet.
#53 Algo así
#28 Eso no sé, pero muchos se pensaban que tener los datos “en el cloud” implicaba automáticamente redundancia a prueba de bombas gestionada por el proveedor al mínimo precio y ahora se han llevado una ostia de realidad
Nuevo logo:
#0 recordar que OVH es el centro de datos más grande de Europa y uno de los más importantes.
#3 Hetzner anda a la par.
#3 ¿"Es" o "era"?
PD: Me parece brutal, no me lo esperaba realmente. Esto les puede hacer perder muchos clientes.
#19 Es.
- https://news.netcraft.com/archives/2021/03/10/ovh-fire.html
- https://w3techs.com/technologies/overview/web_hosting
#3 Donde de trabajo nos ha jodido vivos.
#60 Un conocido me ha comentado esta mañana lo mismo. Ánimo.
#16 Una foto de la famosa migración a la nube.
Dramatización
.
Va a dar más sensación de seguridad una granja de mineros de BTC en China que estos de OVH.
Parece que el tema de la redundancia se lo toman bastante en serio
#42
Con un poco de latencia, pero efectivos, sí...
Con OVH tus datos estás en una nube piroplástica.
¿Se están marcando un Windsor y se equivocaron de centro?
#30 Habrá que esperar a ver si compra el terreno El Corte Inglés.
#0 el follow up por parte de su fundador en Twitter
Creo que les ha afectado el virus del SEPE y han optado por la via rápida para solucionar el problema.
¿Hay alguna mano negra?
#2 Seguramente. Estará chamuscada.
#2 no te extrañe
#35 yo había leído Domain Controller
#68 Si sólo fuese el domain controller estaría chupao
Me cago en la leche. He vuelto a tener un micro infarto. Tengo los servidores en GRA1. Esto ya es tremendamente sospechoso. Voy a tener que plantear tener unos servidores espejo en Amazon. 😤
#38 Yo perdi mi vps en el incendio suerte que tenia backup y lo restaure a otro 👌
#40 Yo tengo programados backups diarios, pero luego, realmente, los saco cada 1 o 2 semanas. Antes tenía automatizado el envío de los backups a otro servidor, pero al final los quité y empecé a bajarme a mano aquellos backups que considero más importantes (evidentemente, casa 1 o 2 semanas). Hay que decir que el servidor de backups lo tenía en el mismo sitio, así que, ante una catástrofe así, estaría igualmente jodido.
La cosa es que, ahora mismo, uno de los servicios que estoy dando NO se puede parar y perder dos semanas de datos ya sería catastrófico.
Debería volverme más desconfiado/precavido con los años, pero parece que cada vez soy más confiado. Hasta que tenga un buen susto. 😑
#41 dos incendios en apenas 3 semanas aún no son suficiente susto?
#38 Si el perder esos servidores es motivo de infarto para ti, si, deberías tener un espejo en algún sitio. Pero eso lo tengas donde lo tengas.
#38 ¿No se podría configurar un autobackup diario y programar para que se te descarguen automáticamente a tu ordenador o algo así?
Debe ser que el mantenimiento debe ser muy cutre. Todas las librerías de almacenamiento tiene alarmas sobre sus sais y fuentes de alimentación con baterías hasta el más cutre lo tiene, y si no le haces caso en muchos casos se apaga el equipo. Pero si esta ahí mucho tiempo el sello se rompe y gotea y produce cortos o hasta fuegos. Esta en todos los manuales. Increíble.
#58 Yo en el último año he recibido tres alertas por incendio de DCs en los que teníamos servicios desplegados. La receta es muy sencilla:
- Se diseña la sala.
- Se pone en producción.
- Se meten unos cuantos racks a mayores porque bien caben y no hay dónde meterlos,
- Se baja un poco la potencia del clima porque este mes ha subido mucho la luz.
- Un par de horas en el horno... y listo para
servirno servir#71 y te faltó las subcontrata, que no tene recursos para atender avisos porque no tiene herramientas. Dígase vehículos, móviles, baterías, discos duros y sigo.....
#72 La verdad es que en DCs no he visto mucha subcontrata, no les debe de dar para tanto. Pero en uno de esos avisos nos decían que sus ténicos estaban solucionando el problema, así que me imagino que además del currículum de sistemas pedirán 5 años de experiencia como bombero
#0 relacionada
Incendio en OVH destruye centro de datos (ENG)
Incendio en OVH destruye centro de datos (ENG)
theregister.com#1 Suerte a toda la gente de OVH que este trabajando en recuperar el DC. #HugOps
.
#21 ¿El DC porque es corriente continua?
#29 DataCenter
Se están tomando en serio, lo de subir los datos a la nube...
Saludos.
#65 Te ha faltado la imagen del meme de Matías Prats.
Dos empleados sufrieron ligeras molestias por los humos.
Pues vale.
#6 A ver si es que se han metido la AstraZeneca
#12 La de moderna que es la que atrae los rayos. Yo creo que lo que quieren borrar aun no lo han conseguido.
#24 Las múltiples zonas son un primer nivel, si de verdad te preocupa que esten tan "cerca" puedes usar múltiples regiones y distribuirlo por todo el planeta, pagándolo eso sí, pero vamos que él que realmente lo necesita tiene la opción.
#32 Con tener tus copias de seguridad en otra región ya te sirve. Si es con otro proveedor y con copias offline, mejor, claro.
Cuando un DC se quema, algo suyo se quema Sr. X
La cosa está que arde.
Menuda racha llevan
Como las lian los de FSociety
Menos mal que mis datos estan en la nube y no en un Datacenter.... Acabarán sacando la nueva gama de servidores: Brûlé servers
Dicen que no hay dos sin tres.
#16 De nube cloud a nube de humo y tiro porque me toca
#39 The Internet is for porn and OVH Servers is for porn. All is for porn.
Mis datos en la nube, noooo
#4
#16 Noooooo!!!!! Se está quemando mi colección porno!!!!!
#36 calentaste demasiado a los circuitos.
#4 Por eso las regiones de AWS tienen al menos tres AZ, con una separacion significativa (AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other) Y cada AZ suele tener mas de un data center independiente. Lo mismo para GPC. Desafortunadamente Azure no sigue estas practicas
#20 Diria que demasiado cerca, eso centros no son anti asteroides y cometas, ni siquiera son anti-caida grave del suministro electrico.
#20 AWS y OVH juegan en ligas diferentes.
OVH esta cubriendo un nicho de negocio, de muy bajo coste y servicios minimos.
Y la responsabilidad (backup, plan de recuperacion,...) recae en quien lo contrata.
#27 Precisamente yo tengo un par de servidores en OVH que si se queman de da igual, los uso para integración continua, despliegues de prueba y hostear alguna que otra tontería. Los puedo sustituir inmediatamente. OVH mola porque es baratillo para estas cosas.
#34 Igual que yo.
Pero fue una putada igual
#20 Lo que no te suelen
decirdestacar mucho cuando se diseña un plan de alta redundancia es que el tráfico dentro de la misma región entre distintas AZ te lo cobran como si fuera entre dos regiones. Luego se monta un proyecto de big data de alta redundancia, miran la factura y flipan#51 Tampoco te destacan que el trafico entre AZs se cobra en ambas direcciones ("in and out") asi que cuando ponen en letra muy pequeña, que en trafico entre AZs es de $0.01/GB en realidad es de $0.01/GB (de salida de la AZ de origin) + $0.01/GB (de entrada en la AZ de destino) === $0.02/GB "
Calcular lo que va a costar algo en AWS (o en Azure, o GPC) es mision imposible.
#4 ahi van
#23
#4 Tus datos se van a la nube, a una nube negra sobre el Data center
Pues Hetzner tuvo también un problema ese día..