Cambiar de proveedor

Estimados, como están?

En los últimos 3 días mi actual proveedor (Datacente1) estuvo fuera de linea unas 5 veces por más de 20 minutos (y en horas pico).
Esto hace imposible el funcionamiento de mi negocio y necesito migrar a otro proveedor.
Tengo un Reseller de 100GBSSD y unas 110 cuentas de hosting dentro del mismo (todas consumen no más que 500MB, son sitios en PHP+MySQL. 5 de esas 110 cuentas tienen más de 40 cuentas de correo funcionando y no mandan más de 20 correos por hora.
Mi presupuesto es de 60/80 dólares por mes.

Alguna recomendación?.

PD: Mientras estaba escribiendo esto, se volvió a caer. ¡Buenísimo!

 

No sé si será distinto nodo, seguramente sí, pero yo tengo un blog funcionando con ellos y no he experimentado ningún corte en ese intervalo horario. ¿Has consultado con ellos la posible causa y descartado que no sea algún problema entre su firewall y tu ordenador?

 

@bbogadod mis disculpas por estos inconvenientes, efectivamente hemos estado experimentando unos extraños y aparentemente inexplicables interrupciones del servicio en servidores virtualizados, lo extraño es que solo sucede en las VM's y el cambio el nodo se mantiene estable y con abundante recursos libres y solo ocurre en algunos pocos, estamos probando un kernel modificado que creo resolverá el problema pero solo tiene una horas y debemos realizar más pruebas antes de captar victoria.

 

Con ese presupuesto puedes coger un dedicado. Si ya estás haciendo el mantenimiento de tu servidor no te supondrá mucho más trabajo (un poco sí) y en cambio tendrías mejor rendimiento.

 

@Aitor, tiene un reseller. ¿Donde has visto que haga mantenimiento del servidor?

 

No lo he visto, por eso he puesto un condicional. Hay personas que llaman "reseller" a cualquier cosa donde puedan alojar varios dominios. En cualquier caso, es un buen presupuesto de partida para mirar opciones.

 

Un saludo bbogadod, encantado de hablar contigo. Datacenter1 es un buen proveedor, yo les daría un margen de confianza, es dificil estar online 24 horas 365 días al año.

 

Opino como copernico, creo que antes de buscar alternativas si estás contento con tu proveedor deberías de darle un voto de confianza. Están trabajando en ello pero muchas veces se necesita un tiempo para estabilizar los problemas y al fin y al cabo un uptime del 100% siempre es imposible, porque de vez en cuando hay que hacer mantenimientos, reiniciar, actualizar cosas, etc. etc.

Un poco de paciencia...

 

Pasa que, ahora mismo, otra vez, todo mi reseller está caído. Yo entiendo que pueden haber errores y eventualidades, pero seis (SEIS!) días seguidos de "eventualidades" causan demasiados problemas. Ya me quedé sin discurso para los clientes (son 110 clientes corporativos).
Sigo buscando un nuevo proveedor, les agradezco mucho a todos.

 

¿Has contactado con Datacenter1? ¿Qué te han dicho?

Y no tienes que dar excusas a tus clientes, simplemente sé sincero y diles la verdad. "Estamos teniendo algunos problemas técnicos y nuestro proveedor está trabajando duro en solucionarlos lo antes posible, actualmente están probando un kernel modificado con el que se espera que los errores sean solucionados. Lamentamos las molestias".

¿Porqué tienes que mentirle a tus clientes? Sé sincero...

Otra cosa es que tu no le estés siendo del todo sincero a tus clientes con el servicio que estás ofreciendo y no sepan que eres un revendedor (que no es una cosa mala, siempre que se vaya con la verdad por delante). Y claro, entonces no puedes serle sincero a tus clientes o descubrirás tus mentiras...

De todos modos no llevas seis días con el servicio caido, llevas unos microcortes en seis días que es totalmente distinto. Y tu mismo has dicho que el microcorte que más ha durado ha sido 20 minutos. Dudo mucho que los 110 clientes se den cuenta por caidas de unos minutos... No creo que haya que darle tanta importancia.

Si estas contento con tu proveedor, ten paciencia y contacta con ellos. Porque te vayas a cualquier proveedor que vayas vas a tener errores como este antes o después. Es totalmente normal fallos de este tipo antes o temprano. Me preocuparía cuando el proveedor no hiciera nada al respecto y se lavara las manos, pero Datacenter1 ha reconocido públicamente en este foro el error (cosa que no tiene obligación alguna de hacer) al igual que han dicho las medidas que están tomando para arreglarlo, eso para mi es un proveedor que se preocupa por el cliente y que no lo encontrarás tan fácilmente. También dijo que es un error que necesita algo de tiempo para testear y que no se podía cantar victoria en unas horas, son realistas, cualquier otro te hubiera dicho "ya está arreglado" y quedarse tan pancho y ellos te dicen "no podemos cantar victoria tan temprano y tenemos que hacer pruebas". Vamos, eso es un buen proveedor.

 

Gracias a todos por los comentarios, esto es un resumen corto:

El error ocurre cuando combinamos MariaDB 10.1 KVM + mysql governor en Centos 7 básicamente MySQL agota todos los recursos cpu, memoria, IO, pasa en nodos tanto en los nodos 24cores/64 GB RAM como en los 40 cores 192 GB RAM todos con 8 discos SSD Samsung Enterprise. la máquina virtual colapsa y deja de responder pero no así el nodo que la contiene, he retirado mysql governor y el problema no volvió a ocurrir, desafortunadamente en uno de los nodos sucedió mientras se retiraba mysql governor y el resuelto fue una corrupción total de mysql (no arrancaba) esto solo sucede en un nodo que aloja unos 28 resellers

De momento hemos colocado mysql en recovery, los clientes están operativos pero sin poder modificar data de mysql, para tratar de hacer que mysql funcione sin necesidad de ir por los backups, pero en caso que la reparación no funcione haremos una restauración de la data mysql con backups de 12 horas antes del fallo

Para clientes y afectados tenemos información actualizada en https://panel.datacenter1.com/announcements.php?id=4

 

Aquel (proveedor) que este libre de pecado (caída) que tire su primera piedra...

Tu proveedor es consciente del problema, esta dando la cara, e intentando solucionar el problema, que por lo que cuenta no es sencillo. Sinceramente, en casi 20 años, aun no he visto el proveedor perfecto a precios normales, aunque he visto muchos que prometían no caerse a precios de escandalo que con el tiempo se han caído, más tarde o más temprano, como todos. No se si te compensará cambiarte, y más si es algo puntual. Como ya te han dicho, y se que no es fácil, lo mejor es que vayas con la verdad por delante con tus clientes.

ánimo, y paciencia.

 

Esto es un pequeño resumen del artículo que preparo para el blog, sin embargo lo comparto acá porque de esta experiencia otros proveedores pueden tomar nota y evitarlo

Primero que nada quiero agradecer @bbogadod por su paciencia y por que (sin querer) ayudó a encontrar la causa

Antecedentes:
Toda nuestra infraestructura de hosting cPanel (reseller y hosting final) está virtualizada con KVM corriendo SolusVM que está siendo reemplazado por Proxmox, usamos servidores mínimo 24 cores y 4 GB de ram por core, adicionalmente tenemos una política de cero overselling, de hecho los nodos tienen 16 a 32 GB de ram adicional, por ejemplo si asignados a los VM 96 GB el nodo principal tendría un mínimo entre 112 a 128 GB ram, adicionalmente tampoco sobrevendemnos los cores y los discos todos tienen 4 u 8 discos SSD samsung PM863 960 GB en arreglos RAID 1o.

Con estas características es bastante que poco probable que una máquina virtual pueda sobrecargar el nodo principal o incluso que un nodo cPanel se sobrecargue ya que de acuerdo a nuestra política de cero overselling colocamos un máximo de 2o clientes x core (clientes finales cPanel) y asignamos 4 GB de RAM por cada core, por cada bloque de 1core/4 GB RAM solo hay entre 20 a 5 clientes finales cPanel).

Para los resellers ofrecemos límites similares, por ejemplo el plan R-100 implica un core dedicado y 4 GB RAM
Tenemos las herramientas para verificar las cuotas de CPU, RAM, IO e IOPS de cada reseller e incluso podemos bajar la velocidad de un reseller si esta comienza a hacer un uso abusivo de los recursos, de esta forma garantizamos dos cosas:

1- Que siempre tendrá a su disposición la totalidad de los recursos contratados (en el caso del plan R100 = 1 Core + 4GB RAM + 100 GB SSD espacio)
2- Que si un reseller se pasa de sus recursos asignados no impactará negativamente a otros y/o al servidor, funciona como VPS 100% administrado

Software:
Utilizamos software bastante estandard que encontrarán en la mayoría de los proveedores y algunos otros no tan comunes para dar el máximo rendimiento y seguridad a nuestros clientes:

• Centos 7
• Cloudlinux
• Litespeed
• Bitninja
• Patchman
• Mod_security
• Cloudflare + Railgun
• MariaDB
• MySQL Governor (temporalmente desintalado en todos los servidores)

La falla inicial:

Varios servidores cPanel comenzaron a presentar fallas a diferentes horas, sin embargo todas las fallas eran en horas de tráfico y día de semana y consistía en el agotamiento total de memoria, cpu y un elevado IO wait al punto que el servidor virtual tenía que ser reiniciado

Los posibles culpables:

Almacenamiento: Un principio y debido a que los primeros afectados fueron servidores usando ZFS pensamos en algún tipo de problemas en el subsistema de almacenamiento, alguna incompatibilidad entre ZFS, La controladora HBA LSI y los discos SSD Samsung (hay reportes de problemas con algunas combinaciones de HBA/RAID con discos no enterprise pero los nuestros todos son Enterprise)

MySQL Governor: Recientemente y luego de pruebas exitosas habíamos pasado a producción a MySQL Governor para tener un mejor control del uso de recursos MySQL debido a que aceptamos conexiones remotas al servidor MySQL, pensamos que MySQL estaba de alguna forma aumentando el i/o wait

Ataques de algún tipo: Nada indicaba una actividad irregular pero nunca se puede descartar, además el falla concidió con una vulnerabilidad del kernel reportada en la cual un atacante podía echar abajo un servidor vulnerable.

Mala configuración de MySQL: Durante la fallas las queries aumentaban considerablemente y conozco de primera mano casos en los que una configuración sobre ajustada de MySQL combinado con malas queries y/o bases de datos con cierto nivel de corrupción pueden hacer estragos en el rendimiento de MySQL

El Diagnóstico:

En un principio no habíamos notado que efectivamente existía un patrón en la frecuencia con la que la falla se originaba, ya que pasaba a diferentes horas en diferentes servidores pero normalmente entre las 08:00 a las 6:00 lunes a viernes, y no fue sino hasta que leí el segundo mensaje de @bbogadod quejándose que estaba pasando en ese momento.

Verificando en Zabbix vi que si existía un patrón y entre las 12:30 a 13:00 había un incremento considerable en la actividad MySQL que si bien muchas veces no era grande, en algunos días si lo era

El verdadero culpable:

cPanel tiene una opción llamada "Use INFORMATION_SCHEMA to acquire MySQL disk usage " que de acuerdo a cPanel es para calcular con mayor exactitud el espacio en disco usado por las bases de datos

Using INFORMATION_SCHEMA ensures that disk usage by MySQL tables is included in totals. However, enabling this option may cause a significant drop in performance as MySQL may become unresponsive until data collection is complete. Disabling this option causes the system to query the filesystem directly, potentially excluding disk space used by some database tables. Note: If you use a remote MySQL server, you must turn this setting On in order to calculate MySQL disk usage.​

Este script es muy intensivo con MySQL y por defecto cron lo ejecuta cada 4 horas, es decir con seguridad al menos una y hasta dos veces al día y en horario pico el script correrá y cuando se juntaba con un snapshot cada hora + más MySQL Governor tratando de contener el uso agresivo de MySQL el resultaba el colapso completo.

La solución:
Desactivar Use INFORMATION_SCHEMA to acquire MySQL disk usage y cambiar la hora del cron para la madrugada
Nota: Los upgrade de cPanel lo volverán a colocar a cada 4 horas, pero estimo que con desactivar la característica en cPanel basta.

Daño colateral:

En un nodo el MySQL quedó inservible y con un alto nivel de corrupción en las bases de datos, sin embargo esto NO fue causado por el script cPanel o MySQL Governor sino por los reboots con el servidor colapsado mas el hecho de haber estado desinstalado MySQL Governor justo en el momento que comenzó el problema.

NOTA: Si está es la versión corta solo imagina como será la larga

De nuevo agradezco a todos por sus comentarios y especialmente a @bbogadod por su paciencia así como a la de los otros clientes afectados

 

Olvidé mencionar el script cron

CODE, HTML o PHP Insertado:

30 */4 * * * /usr/bin/test -x /usr/local/cpanel/scripts/update_db_cache && /usr/local/cpanel/scripts/update_db_cache

No hay inconvenientes si se pasa a una vez al día, pero probablemente sea más seguro desactivar Use INFORMATION_SCHEMA to acquire MySQL disk usage ya que igualmente cpanel continuará tomando en cuenta el espacio en disco usado solo que sin tener que llamar a mysql y consultar el uso de cada usuario/base de datos

Otro dato es que ese script es verdaderamente lento en un servidor con 800 bases de datos (toma 30 minutos en finalizar)
Estoy investigando si esa lentitud es exclusiva de nuestro setup o causada por MariaDB 10.1

 

Hoy me acorde de vosotros porque salió la explicación de las caídas de Amazon de estos días, pero es que estos días fue Amazon, el otro día Google, el otro día Facebook,... ¿proveedor perfecto? No existe aunque hay proveedores competentes que solucionan y toman medidas, y sobretodo, aprenden de los problemas y dan la cara.

 

Si todos los grandes se han caído esta semana :0 Amazon, Google, Facebook, Datacenter1... jaja

Dos días sin dormir me costó el "problemita" este.

 

anda anda... yo llevo un mes... pasando todos los servidores que quedan a ssd, y todos los sistemas operativos centos5 a centos7 con puñeteras migraciones que...

 

Yo ya he dejado oficialmente de vender discos sata, los que quedan los ofreceré gratis a los clientes dedicados para backups locales, suerte con eso!

 

Un placer Guillermo, gracias por la solución al problema.

 

Hola @bbogadod , quisiera probar el servicio de datacenter1, nos puedes comentar cómo siguió tu experiencia con ellos desde Marzo hasta la fecha.
Gracias.