El viernes noté un incremento al load de un server del trabajo, así que hice u nscript, sobre el que estoy trabajando en este momento, que me dice varias cosas. Sin embargo no me gustó darme cuenta que dejé un pendiente durante años.

Un script central de monitoreo de Servidores en cuanto a loads , contenido, accounts, memoria y ps aux o procesos corriendo. Lo hice e inclusive puede ser un producto vendible con algo mas de pulimiento.

Sin embargo, debo mantenerlo simple. Si bien ya me da los datos de carga de cuatro servidores (cosa que solo Nagios hace por lo que sé) el tiempo de respuesta es óptimo y así debe ser.

A diferencia del defrag de windows 7, que me dice «paso 26» bla bla bla… varias de las cosas valiosas, aunque hay excepciones, deben poderse hacer en cinco pasos o menos.

Por mientras ya emití la orden de cancelación del server que no voy a renovar, así que este fin de semana deberé respaldar / mover varias cuentas.

Ayer estuve revisando problemas de load alerts en cuatro servers diferentes, en tres datacenters diferentes.

Cada uno se contrató en un lugar diferente, pero todos con las mismas características.
Y uno me dice : 1024 (lo que es)
Otro : 1512 (50% bonus, ok)
Otro : 2048 (100% bonus, ok, ese proveedor es conocido que actualizó todo)
Otro : 4096 ???

Asi que resulta que o cpanel maneja diferente la forma de dar el burst ultimamente, o el proveedor que esta dando 1024 me quitó el burst cuando separé el cluster.

Hice este script que da bastante información util, aunque debe saberse que esperar de los diferentes buffers bajo Linux. En lo personal, este script es el que decidió mi auto pregunta de ayer.

El gethostbyname lo uso para saber la ip aunque esté corriendo bajo IIS y no Apache.

http://www.alfonsoorozcoaguilar.com/codigo/memoriaburst.txt

Por cuestiones de trabajo he estado haciendo varios experimentos y cuestionarios. Por las Asociaciones civiles (independientes de mi trabajo por nómina) estoy controlando tres servidores y tres clusters en diferentes datacenters. (los clusters son hpshere y los servidores cpanel focalizados resultado de dividir el cluster que tenía el año pasado en cpanel.)

Ayer fue un día bastante productivo, porque al estar probando lobonegro, el analizador de código, encontré un problema con el uso que está haciendo google y otros sistemas en cuanto a consumo de memoria con los subprocesos de apache. Así que me encuentro en uno de esos momentos que de plano si por mi fuera instalaría lightspeed en todos los servidores.

ya estooy manejando round robbin pero los datos que siguen no lo consideran para no meter ruido en la comparación:

Por partes:
Servidor Uno esta manejando clientes de una AC y un dominio propio que es el de tiene los nameservers. Tiene un poco de información propia en un dominio pero puedo pasarlo a otro server y olvidarme de el. Consumo de ancho de banda mes pasado, 65gb aprox, 4 gb de uso en disco duro, 10 accounts.

Servidor Dos: De todo un poco. Maneja dos dominios que no puedo mover de ahí porque la dirección ip la usa el cliente para sus soincwalls en sus sucursales. Lo siento un poco inestable pero tengo que revisar con calma las alertas de recursos y hacer un scripts para guardar los loads por cron. 36 cuentas que puedo reducir a 30. Maneja cientos de dominios propios a travñes de un script php, pero no creo que sea eso parte del problema. Probablemente reduciendo a 30 accounts pueda evaluarlo mejor.
15g de ancho de banda, unos dos a 3 gb en uso de disco duro.

Servidor Tres: 20 gb de trafico, que son los foros donados. 3 gb de espacio, 19 acccounts.

El problema se debe a que suena bonito mezclar los tres en un cluster, pero el cluster sale mas caro, no da round robbin, y tengo las ventajas de que un solo punto de falla no tira los tres. De momento lo que me parece mas decente es trabajar en el servidor tres para reducirlo a 12, y en la medida de lo posible desaparecerlo a mediados de mes. La pregunta es…

¿Adonde muevo los dominios que estan siendo visitados por google todo el santo dia?

Una opción es moverlos al server dos y subirle la memoria . El costo es el mismo y puedo crearme nuevos problemas.

Otra es migrarlo a clusters. No se cual sea el rendimiento en hpshere de los foros de invision.

La tercera es contratar otro server en otro lugar y migrarlo pero donde estan no dan problemas.

Decidiré en el transcurso de este mes.

Hace unos años era habitual usar sistemas en modo cgi-bin , y PHP tiene soporte para modo CGI además de texto. Normalmente Cgi no tiene problemas si esta bien documentado, y pasé una buena parte del día de hoy configurando un software de CGI en perl bajo Cpanel.

Por lo menos ya pasé de la ventana de setup, pero que me costó, me costó.

El problema estaba en dos factores después de instalar los módulos de Perl:

1 ) El instalador del software no es intuitivo. Pude resolver la mayor parte del problema gracias a que si no estaba el archivo de configuración, un «check» avisaba si faltaba algo. Me decía que el host cumplía los requisitos. Así que pude saber que el problema era el config.
2 ) el software de marras estaba diseñado para jalar en perl, y trae mal la ruta del script . Ensayo y error funcionó.. ruta por ruta.

Ahora entiendo porque este es el primer programa en cgi obligatorio que veo en en los ultimos cinco años. No creo que Movable Type pase del 2013. Se estpan dando en la torre solos.

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.

Una de las cosas extrañas es que el gobierno para algunos procesos de México pide personas certificadas en CCISP (http://en.wikipedia.org/wiki/Certified_Information_Systems_Security_Professional) y CRISK.

Lo malo es que para lo que nosotros vamos a hacer, una certificación CCMI2 o una CISA son las correctas.

Revisé con dos contactos que tienen certificaciones ISO Lead Auditor para 27001 y también se sacaron de onda por el contexto. Uno de ellos comentó que esas certificaciones no son costeables, y la otra hace certificaciones de 27001 para Secofi.

Parece camisa hecha a la medida, porque segun lo que yo se ni siquiera hay quien certifique en México para CRISK (que por otra parte no necesito aunque una de mis especialidades es la continuidad de negocio de ONG)

De todos modos, los contactos con diversas secretarías de estado me hacen pensar que la burocracia de México es surrealista, para decirlo decentemente.

Noté un problema raro con este dominio hace unos dias, que resultó ser un problema de que las bases de datos estan en Miami y el host en otro estado. Ya se supone que lo estan verificando, pero no se ve bien.

Hice un codigo simple para validar el tiempo de carga real de manera externa, necesita Curl.
======================================
$url=’http://www.Example.com’; loadtime($url);

function loadtime($url){
echo «
Testing time needed to serve the Url: $url»;
$starttime = microtime();
$startarray = explode(» «, $starttime);
$starttime = $startarray[1] + $startarray[0];
file_get_contents($url);
$endtime = microtime();
$endarray = explode(» «, $endtime);
$endtime = $endarray[1] + $endarray[0];
$totaltime = ($endtime – $starttime);
echo » $totaltime»;
} // loadtime
======================================

Ayudando a la persona del CMS GPL que decía ayer, me puse a investigar porqué el minieditor causa problemas diversos.

El me pidió ayuda sobre los caracteres raros (htmlentities lo resolvió), pero lo que me choca es el limite duro de alrededor de 4k por mensaje. El problema parece residir en la forma en que funciona INNERHTML para procesar nodos de texto grandes.

De entrada Innerhtml es una forma elegante o sucia según a quien se le pregunte, para solución rápida de edición online, pero es la unica si se requiere compatibilidad con IE 5 o 6, que no soportan el estandard DOM completo.

Una búsqueda a detalle de los nodos y su limite, me hace pensar que el problema puede ser por sistema operativo. Lo probé en la toshiba del trabajo (windows home premium), explorer 8 ff y chrome actualizados, y lo mejor es chrome en cuanto a largo. Sin embargo, opera 9 y 11 se cortan a 2k aunque el supuesto largo de opera 9 es 32k.

En resumen: Ese cms es excelente para contenido corto. Quizá un ajuste de 1 kb aprox, me permita editar de 20 a 32k por un post / textarea standard. Interesante de todos modos.

El fork se impone.

Esta semana he estado colaborando en un sistema opensoruce del que supongo puedo hacer un fork, es un CMS bastante decente con el problema que solo maneja texto de menos de 4k por entrada por limitaciones de post pero es una idea bastante decente. Hay un problemita que quedé de arreglar para mañana (no introducido por mi) por codigo que no es utf8.

El fork pensaba hacerlo en lobo blanco.

Lo bueno es que me quedaba un solo cliente en el server loboblanco y estoy en proceso de migración pero implica cambiar de una plataforma a otra (hsphere a cpanel)

Este es el checklist aproximado hecho y por hacer:

Checklist para migrar Dominios de hsphere a Cpanel.

Hecho:
1 ) suspender el account del dominio actual
2 ) respaldar base de datos por base de datos en archivos independientes.
3 ) respaldar files del dominio (170 mb aprox)
4 ) crear en nuevo server el dominio
5 ) preparar las cuentas de correo
6 ) migrar el contenido de las cuentas de correo
7 ) subir el respaldo del punto 3

Sigue:

1 ) Subir el respaldo y verificarlo
2 ) Crear bases de datos en nuevo server.
3 ) Migrar dominio en el registrar para que apunte al nuevo servidor
4 ) editar mi archivo hosts para estar seguros que esta apuntando al nuevo server.
5 ) subir bases de datos al nuevo server.
6 ) ajustar las aplicaciones
7 ) probar aplicación por aplicación
8 ) sacar respaldo nuevo ok y descargarlo
9 ) ajustes y pruebas a cuentas de correo.
10 ) despues de unos dias, eliminar el account de hsphere

Hace un momento quiise entrar a este blog y me dió un problema secundario extraño como si el load del cluster fuera excesivo.

El proveedor estaba funcionando raro a principios del año pasado y se corrigió a mediados, pero los ajustes que hizo la semana pasada pueden estar pasando la factura.

Estamos en proceso de estabilización de servers con el, y espero que el próximo fin de semana se elimine el cluster lobogris, quedando solamente lobonegro.

Sin embargo, creo que de todo el cluster los dominios actuales menos este y un foro de Dark Crow no usan bases de datos, asi que no debería ser un load alto en estas circunstancias. Observaré.

El analizador de código probablemente sale al aire en versión beta hoy o mañana.

UPDATE: El proveedor dejó el server de base de datos en el otro cluster… Los sitios estáticos se cargan de volada pero no aquellos con base de datos.