Del cluster lobogris me movieron las ip sin avisar, ya las chequé y se supone que el tiempo ya bajó bastante después de cambiar los scripts de conexión (unas cuatro a ocho horas no dieron respuesta algunos sitios pero ahora ya noto la diferencia aunque no están optimizados todavía).

Y en la oficina, el internet se volvió a caer.

Desde el año 2003 empecé a hacer experimentos en diversos paneles de control para dominios, que son las interfaces gráficas que permiten administrar un dominio web.

Sin embargo, varios de ellos han ido quedando desfasados a mis necesidades (helm por ser bastante hackeable, plesk por cobrar por dominio y ser medio pesado para la máquina, Ensim porque el unico proveedor confiable ya no existe, etc)

Por lo mismo, hay razones para estar monitoreando los paneles de control mas populares que siguen, que de momento son HSPHERE y CPANEL.

En estos momentos del Panel HSPHERE hay dos proveedores confiables, de los cuales tengo uno para los clusters a lso que llamo Lobonegro y lobogris. Sin embargo, desde hace unos ocho días he notado que la configuración del MYSQL de lobonegro está teniendo problemas eventuales.

En la práctica esto significa que dominios desarrollados de manera externa, y que están en desarrollo (como este), NO deben estar ahí. La interfase phpMyadmin no es el problema, ya que mi versión reducida (mychelle.php) da los mismos problemas de conectividad.

Parece ser que cuando un usuario hace algo intensivo, por ejemplo, ejecutar un script sql con 200 inserts o refrescar una consulta php, la dirección IP es "banneada" desde servidor del cluster que ejecuta MYSQL por dos a tres minutos, porque el sitio sigue resolviendo paginas html y el php puede usando proxies.

En la práctica esto hace que el cluster ne cuestión no sirva para desarrollo, así que hay que tomar medidas (pasaré a loborojo en CPANEL este dominio y otros más)

Algo que me llama la atención es el anuncio reciente de RC diciendo que van a usar CPANEL. Espero que eso NO implique desaparecer su panel de control propio porque al momento eran la mejor opción para dominios con mas de 15 gb de espacio.

Cambiaré este dominio a LoboRojo (cpanel), por lo menos de manera temporal, en el transcurso del día.

Hace 20 minutos pude por fin ponerme en contacto con el técnico de costumbre del Proveedor en cuestión.

Recuperó el archivo.

Eso es lo esencial.

Aunque le proveedor no sea el mas económico ni rápido, una vez que se encuentra a la persona esencial, el asunto se resuelve.

Lo malo de los datacenter, es que no todos los admin son de la misma calidad. Este server / CLuster hsphere, tiene un admin decente al que contactar, pero lo ponen de ultimo recurso.

Seguiré usando HSPHERE pero solo como uno de los nodos no esenciales.

El dia de ayer fue bastante complicado por una corrupción de un archivo PHP en un servidor bastante confiable bajo HSPHERE. El problema fue que el cliente no tenía respaldo, y se dañó un php crítico para su negocio que estaba modificando cuando al cliente se le fue la energía electrica. Los servidores HSPHERE complican un poco los negocios, en el sentido que uno como proveedor debe pedir ayuda al datacenter para que lo manejen.

Las conclusiones a las que esto me lleva son, que HSPHERE no tiene el poder necesario para un desarrollador, al no tener el control sobre el server. Alguna vez leí que un server es tan bueno como su admin, pero esa es una arma de dos filos. Mi filosofía como parte de los dominios que dono a causas sociales, es explicar a los usuarios COMO sacar respaldo, y decirles que mis servicios DONADOS; no incluyen sacar respaldo de sus proyectos.

He visto que a pesar de la falta de versatilidad de los hosts de RC, al no tener PHPMYADMIN, son prácticos para desarrolladores. Por lo mismo, supongo que varios de mis propios proyectos los acabaré pasando a un solo dominio hosteado en RC, o, probablemente, a un nuevo servidor DIRECT ADMIN hecho a propósito para ese fin.
Sin embargo, es un poco preocupante la falta de control por tantas capas intermedias, y seguimos sin poder resolver problemas que se resolvian de manera simple con ENSIM u otros paneles de control.

Uno de los productos que he desarrollado como empresa (y que suelo ofrecer libre de cargo a clientes por ser hecho bajo LGPL y con código) es un Sistema de tickets/helpdesk. Cuando entré hace unas horas a poner el ticket con mi proveedor, era un sistema bajo CERBERUS como software de Helpdesk, y tuve timeouts desde dos ISP diferentes, no se veia nada e inclusive use unos sistemas de Proxies para consultar desde un tercero. Al minuto y medio se cargó la pantalla, pero para mi esto es una señal de lo que no debe hacerse, lo que puede desesperar a un cliente.

Igualmente los precios de los dominios han subido de manera extraña y las interfases son cada vez mas saturadas de información basura.

La infraestructura que tenemos detrás los proveedores de hosts, como yo, va siendo cada vez menos manejable y siendo al mismo tiempo mas lenta, y llena de formas innecesarias o revisiones que por sentido común no deberían permitirse. Tratando de simplificar la red hemos llegado a usar una capa para referirnos a otra capa, y en cada capa de proveedores intermedios hay legacy apuntando a cosas tipo magic quotes de PHP, que por principio de cuentas nunca fueron realmente necesarias para un servidor en producción.

El reto es entonces mantener costos decentes, junto con integridad de servicios, en varios proveedores a la vez. El incidente de ayer para mi es un gran indicador que el futuro puede tener actualizaciones automaticas tipo CPANEL(que no por eso son buenas), pero realmente, en los sitios críticos, deben estar en servidores dedicados o en infraestructuras externas con menos puntos posibles de fallas. Es decir, no es posible que la infraestructura de los negocios en un futuro este basada en una serie de anuncios, o en algo que no este bajo nuestro control : Los mismos proveedores de datacenters que usan CERBERUS deberían de hacer pruebas de que entra en menos de un minuto, o tomar otra medida.

Esto me lleva a pensdar que en el futuro cercano, moveré varios sitios pequeños a HSPHERE de proyectos donados, pero todos los realmente importantes, mios, estarán en un server dedicado independiente de mis clientes, o por lo menos en un VPS replicado con Round Robbin y bajo mi control de una manera mas directa (cpanel o direct admin)

Lo esencial es entonces lo que se está perdiendo: La funcionalidad de la supuesta nube no es tal, ya uqe hay cada vez mas puntos de falla. El problema básico es que verificar lso puntos de falla implica dinero, y aunque se usen proveedores inteligentes (como el datacenter en que estoy de HSPHERE), ocasionalmente cometen errores absolutamente estúpidos, que pueden crear problemas por tratar de llevarse a uno a algo mas que lo esencial.

Lo esencial es cumplir el objetivo. Lo demás sobra.

Los precios de dominios y las funcionalidades de los diferentes proveedores debe tenerse presente para poder, en realidad, manejar ciertas cosas a prueba de fallas, pero veo que desde el punto de vista de NO BLUFF y estabilidad, MONIKER sigue siendo de lo mejor que hay, y SRSPLUS.

La estrategia a seguir con los cambios de precios es algo que seguiré verificando, pero por mientras, seguiré en software propio en otro nuevo proyecto. No voy a confiar en intermediarios ni en códigos como WordPress, que son pesados, consumen recursos y deben actualizarse de manera continua. De manera temporal tampoco permitiré comentarios en lo que establezco esa función, pero integraré una serie de proyectos sobre lo que esta pasando en la red, y el mundo de dominios (mas implicaciones filosóficas), en un dominio con mi nombre, porque después de todo el negocio de dominios no es tal, lo que importa es el contenido. Pierdo a veces clientes como parte de su incapacidad para poner contenido, pero mi objetivo sigue cumjpliendose. Para mi, el hostear dominios de clientes / asociaciones civiles, es secundario al desarrollo de sistemas, que es la verdadera fuente de ingresos.

Eso es lo esencial.

No puedo buscar ofertas en ciertas cosas, ni tampoco lo mas caro. Lo que cumple lo esencial, a traves de Round Robbin, ha sido la solución correcta desde hace mas de 10 años, dependiendo en lo menos posible de soluciones cerradas.

Seguimos en
www.alfonsoorozcoaguilar.com

Ojos Alerta AC
Director General.

Hace un rato empecé a preparar la transferencia de varios dominios de cpanel a hsphere, y no pude activar catch all ( recibir correos a cuentas de correo que no existen ). Entendible. Lo que me cayó de la patada, fue que no avisaban que el nuevo cluster NO los admite. Cinco de mis clientes si necesitan catch all, asi que voy a tener que conservar el viejo… organizado de manera diferente.

A ojo de buen cubero Segun mis cuentas de dominios propios solo tres requieren catch all. Otra cosa mas a revisar.