NubeBlog | Web Hosting en la Nube

Archivos de Tags: hosting

Google utiliza cloud hosting para reducir su huella de carbón

El web hosting en la nube es seguro, simple, mantiene la productividad y ahorra dinero. Pero la nube también puede ahorrar energía. Un estudio reciente hecho por el “Carbon Dislosure Project” (CDP) y Verdantix estiman que la computación en la nube tiene el potencial de reducir las emisiones globales de carbono por un millón de toneladas métricas. Jonathan Koomey, un profesor de Stanford que ha liderado diversos estudios en el uso de energía en los centros de datos (Datacenters), sostiene que la computación en la nube “es significativamente más eficiente energéticamente que la computación hospedada in situ”

Desde hace ya tiempo que Google utiliza las tecnologías en la nube, y están comprometidos con el medio ambiente. Prueba de ello son todas las medidas que han adoptado para reducir su huella de carbono, y constantemente analizan sus servicios para compararlas con otras alternativas más eficientes.

Más de 4 millones de empresas han cambiado sus servicios de correo a Gmail, el cual no solamente provee una bonita interfase y muchas herramientas, sino que es alrededor de 80 veces más eficiente energéticamente hablando que un sistema de correo hospedado en servidores de la empresa. Esto se debe a que las tecnologías de hosting en la nube (cloud hosting) son hospedados en centros de datos altamente eficientes que operan a un porcentaje mayor de utilización del servidor, y utilizan hardware y software especialmente diseñados para esa aplicación, condiciones que pequeñas empresas rara vez pueden crear por si solas.

Una ilustración de utilización de servidores ineficiente de las pequeñas empresas comparadas a una utilización más eficiente en la nube. (Fuente: http://gmailblog.blogspot.com/2011/09/gmail-its-cooler-in-cloud.html)

Todavía hay mucho que aprender de los impactos globales de la computación en la nube, pero una cosa podemos afirmar con certeza, la utilización de servicios de email, video, o hosting de websites son más eficientes y ecológicas en servidores en la nube, ayudando así a reducir los efectos del cambio climático en nuestro planeta.

Fuentes:
http://gmailblog.blogspot.com/2011/09/gmail-its-cooler-in-cloud.html
https://www.cdproject.net/en-US/WhatWeDo/Pages/Cloud-Computing.aspx 

El Datacenter Colo4 de Dallas se queda sin suministro eléctrico

Colo4 es un datacenter estratégicamente ubicado en Texas, que desde el año 2000 provee servicios de colocación de servidores para empresas y organizaciones de todo el mundo. Es un datacenter que ofrece garantías como cualquier otro, staff las 24 horas del día, 365 días del año, con 100% de uptime, multiples proveedores de redes, etc. Proveen altos estándares de confiabilidad y desempeño para sus clientes.

Hoy 10 de agosto del 2011, la tecnología les hizo una mala jugada, ya que el datacenter tuvo ciertas complicaciones en su sistema de suministro eléctrico a partir desde las 11am CST. Se estima que decenas de miles de websites están fuera de línea incluídos muchos proveedores de hosting, VPS y servidores dedicados, en su mayoría empresas mexicanas y estadounidenses. Los reclamos no se hicieron esperaron en las redes sociales de Facebook y Twitter, y no es para menos, ya que el apagón se traduce en pérdidas económicas para las empresas cuyos websites están alojados aquí.

Las noticias sobre la actual situación están siendo dadas a conocer a través del portal de colo4, quien a las 13:05 horas notificó que estaban teniendo problemas con 1 de sus 6 entradas de energía, y coincidió con una falla en el switch automático de transferencia ATS.

Así mismo se especulaba si la causa del incidente pudiera atribuirse al intenso calor que se vive en Dallas o al suministro de la red eléctrica de la ciudad, lo cual el proveedor descartó.

Por lo pronto todos los esfuerzos del datacenter están enfocados en reestablecer el suministro eléctrico, el cual estiman tardará más de lo previsto, ya que como dicen, es muy diferente a encender un carro con cables de corriente. La hora prevista para reestablecer sus servicios se estima entre las 6:15pm y 7:00pm CST. Colo4 prometió a sus clientes una explicación más a detalle después del incidente.

fuente: www.colo4.com

¿Qué tal si revisas que tus backups sirvan realmente?

Los backups son una de las cosas que todo usuario prudente debería saber muy bien hacer y mantenerlos al día; no esperar a que La Ley de Murphy haga de las suyas con el fallo de un disco duro, o cualquier otro desastre que le pueda pasar a una computadora o servidor.

Después de todo, para mantener backups todo lo que se necesita son las herramientas apropiadas y principalmente la disciplina de crearlos constantemente; si crees que eres incapaz de tener tal responsabilidad, buscar algún programa o haz un script que se encargue por ti de general puntualmente los respaldos de tus archivos/sitios/bases de datos… a menos que quieras que te suceda lo mismo que a Ma.gnolia a inicios de este año.

Pero hay que tener algo claro: una cosa es tener backups y otra haberse recuperado a partir de estos; hay que estar seguros que realmente podamos recuperar toda (o casi) nuestra información, no solo los datos sino también configuraciones, compilaciones de los programas y metadata de la cual dependamos.

¿Alguna vez has hecho la simulación de recuperar tus datos a partir de tus backups? ¿Tienes una copia en otro Datacenter? ¿Sabes cuanto tiempo tardarás en tener todo de vuelta? ¿Estás seguro que si falla el disco duro del servidor, puedes recuperar todo? Todo esto viene a que Jeff Atwood, de Coding Horror, recientemente tuvo un problema con su servidor y de pronto casi había perdido todo sitio, por confiar los respaldos su información a terceros.

No es la primera vez que hablamos de backups, herramientas y sitios relacionados acá en Maestros del Web:

De hecho mientras escribía este artículo, hice una copia completa de los sitios que administro, incluyendo:

  • Un .tar de los archivos de cada sitio.
  • Un sqldump de cada base de datos.
  • Copias de los httpd.conf, my.conf, php.ini y otros archivos relacionados con la configuración del servidor
  • Estas copias quedan en el disco secundario del servidor.
  • Aparte, todo esto lo envíe a Amazon S3, desde cada servidor. Cada cierto tiempo bajo una de las copias que están en S3 hacia mi máquina local.
  • Sumado a la copia diaria de los sitios que CPanel genera.

Todo esto lo hago con la ayuda de un script basado en los comandos que toda distribución GNU/Linux incluye, para enviar archivos hacia S3 desde el servidor lo hago con S3Sync.

En el caso de mi Desktop, aunque la mayoría de datos ya están en la nube, trato de mantener al día mis respaldos hacia un disco duro externo y uso JungleDisk para enviar lo más importante hacia S3

… ¿Y si de pronto nuestros servidores/datacenter mueren?

En el tiempo que tengo administrando sitios, ya he pasado por experiencias en las que debemos levantar una copia completa del sitio en otro servidor, y mientras menos tiempo pase abajo mejor. Idealmente tendríamos una infraestructura de respaldo capaz de manejar todo el tráfico del sitio, y que se mantengan sincronizados respecto a nuestros backups, minimizando el tiempo que el sitio pasaría fuera de linea.

Otra idea, sería provechar el Cloud hosting, Amazon EC2 por ejemplo, mantener imágenes listas con las cuales podamos iniciar instancias y levantar nuestra infraestructura en la nube; pero con la ventaja que si no la usamos, pagaríamos un precio mucho menor que tener un servidor dedicado sin uso.

En fin, si aún no tienen backups completos de su información, háganlos ya mismo. Si ya los tienen, hagan una prueba para recuperarse a partir de estos. ¿Cuanto tiempo pueden perder? Seguro mucho menos que empezar a rescatar las cenizas en caso de desastre. Todo es cuestión de disciplina

Fuente: www.maestrosdelweb.com

Guía para trasladar tu sitio de hosting sin dejarlo abajo ni un minuto

Uno de los mayores inconvenientes de como funciona actualmente Internet, es la eternidad que toma la propagación de los cambios en los DNS’s. Desde hace algún tiempo he resuelto este inconveniente al usar OpenDNS, pero casi todo el mundo sigue dependiendo de los DNS’s de su ISP y/o Empresa. Estos cambios pueden tomar incluso hasta varios días, dependiendo de como estén configurados los diferentes servidores DNS.

Aún con el inconveniente de la propagación de los DNS’s, cuando uno cambia su sitio web hacia un proveedor de hosting diferente (un datacenter totalmente aparte del actual), uno no tiene porque dejar su sitio fuera de servicio para aquellos que aún no ven los cambios, ni perder tráfico de ninguna forma. Aquí te contamos como hacerlo.

Antes de mudarte

  1. Suponiendo que ya has elegido el proveedor al cual te vas a cambiar, procura iniciar el proceso de mudanza con varios días, o semanas si prefieres, antes de que canceles tu cuenta en el proveedor actual. Esto te dará el tiempo necesario para solicitar los cambios necesarios en el nuevo servidor (o pedir el dinero de regreso XD)
  2. Configura un subdominio de pruebas hacia el nuevo servidor. Aún cuando los servidores/ambientes puedan parecer idénticos, casi siempre hay pequeñas diferencias que pueden arruinarte el sitio web.
  3. Si tienes acceso via SSH a ambos servidores, considera transferir los archivos de servidor a servidor; es mucho más rápido que bajarlos primero a tu máquina y luego subirlos al nuevo servidor. Tal vez necesites repasar la sintaxis de los comandos necesarios: mysqldump, tar, gzip y sftp.

¿Se te dificulta agregar un subdominio apuntado a otra IP? Edita tu archivo hosts y agrega una linea como esta:

www.tudominio.com       1.2.3.4

1.2.3.4 representa la nueva dirección IP. Esto te permitirá conectarte a tu nuevo servidor como si hay hubieras hecho los cambios en tu dominio.

Día de la mudanza

Si lograste configurar un subdominio de pruebas, seguro ya tienes todo listo para mudarte hacia el nuevo servidor:

  1. Transfiere los archivos que se hayan actualizado desde que configuraste el subdominio de pruebas. Quizás solo necesites pasar las bases de datos y algunos archivos. Si es posible, hazlo de servidor a servidor via SFTP
  2. En el servidor anterior considera dejarlo en modo “solo lectura” a los visitantes; por ejemplo, cerrando los comentarios en los posts si estás mudando un blog. También puedes dejar un aviso en alguna parte del sitio
  3. Si usas los name servers de tu proveedor de hosting, apúntalos hacia las nuevas direcciones IPs. Esto lo puedes hacer en cualquier VPS o servidor dedicado, con un shared hosting ese menos probable que tengas esta opción.
  4. Ahora si, ve a tu registrador de dominios y modifica los name servers de tu dominio para usar los de tu nuevo proveedor de hosting. Si usas los name servers de tu proveedor de hosting o alguno otro ajeno a tu hosting, este paso no sería necesario, solamente el anterior (cambiar las IPs).
  5. Todos estos cambios deberían estar listos en pocos minutos, pero por la propagación de DNS’s es que puede durar hasta días. Usa OpenDNS para verlos antes que la mayoría, limpia el cache para tu dominio si fuera necesario;
  6. Revisa que todo esté funcionando correctamente y espera la propagación de DNS’s tenga efecto y el nuevo servidor recibe todo el tráfico. Deberías esperar al menos una semana
  7. Elimina todos los archivos de tu servidor anterior y cancela tu cuenta. Deja que tu sitio disfrute se nuevo hogar

Como ves, estos no son pasos extraordinarios pero si los sigues correctamente puede que te ahorres muchos dolores de cabeza, dinero y perdidas de tráfico.

Fuente: www.maestrosdelweb.com

afiliados