Hola :) El Tuesday 17 March 2009, Shinji Ikari escribió:
Meh... bueno no se si estará bien que me meta en este hilo, considerando que mi conocimiento respecto a sistemas críticos o sistemas de negocios es null. Pero vale, fuerzas de flaqueza.
No te preocupes que todo el mundo tiene derecho a opinar ;)
On Tuesday 17 March 2009 08:16:14 Camaleón wrote:
El 2009-03-17 a las 13:13 +0100, Rafa Grimán escribió:
El Tuesday 17 March 2009, Camaleón escribió:
Por eso mismo. Que el sistema se cuelgue, es normal.
Pero _NO_ debería serlo.
No, claro, pero sucede.
¿Que sucede? ¿Los cuelgües? Es como pensar que el trabajador va a poder asistir todos los días a trabajar sin falta, sin enfermedad o problemas. Estamos en un mundo donde perfección es variable. =P
Cierto, pero me refería a que en la informática es demasiado habitual :(
Que haya apagones, también. Que no haya un SAI, también.
No debería ser normal no tener un SAI.
Hombre, no todos tienen los recursos necesarios para tenerlo y no por ello tienen que arriesgar sus datos cada vez que encienden el equipo O:-)
Vale, hay muchos que no los tienen, pero si aprecian su información y sus equipos deberían pensar en adquirirlos. Las utilidades que se les paga a los accionistas tienen poco valor para el crecimiento de la empresa. Inversión señores, inversión.
Eso es lo que hace falta. [...]
Yo espero lo mismo en informática, espero la misma fiabilidad y que que el hecho de apagar el sistema a lo bruto no termine en una pérdida de datos.
Eso se lo puede pedir a empresas grandes que garantizan sus soluciones, HP, IBM. Si recuerda, hace un tiempo atrás pasé una página web con vídeos donde prueban equipos. HP probó sus equipos contra disparos y una explosión (supuestamente recuperaron toda su información y se supongo minimizaron perdidas por la interrupción). No tengo idea de como serán esos contratos, tal vez el Sr. Griman pueda comentar al respecto, pero... me atrevo a considerar que perdidas por error en el sistema se menciona y la empresa prestadora no se hace responsable.
Eso son contratos muy personalizados porque claro, puede pasar que haya un terremoto y se hunda el edificio entero. Son contratos muy complicados en el que los abogados de ambos lados se tiran hablando mucho tiempo.
La parte por el todo no puede ser, no es de rigor. Los problemas hay que aislarlos y no pueden afectar a todo el conjunto, sólo, claro está, en casos extremos. Por ejemplo, si quito el pilar central de un edificio, con el tiempo y factores externos se acabará por derrumbar. Pero no compares quitar un pilar base con apagar el sistema de forma abrupta :-)
¿hmm? No conozco de sistemas que se autocorrijan, ¿y cuanto cuestan? =P Ni siquiera el cuerpo humano es inmune. Si se enferma una parte, el resto es afectado, sea por como es el sistema o la especialización y dependencia de cada parte.
Tome en consideración también que si retira o se encuentran fallos en la columna principal del edificio que menciona, el ente encargado de las construcciones lo califica como no habitable. Tal vez pueda resistir otro sismo, u desastre o que sea utilizado, pero... ¿se arriesgaría? =P~
Buen punto, en onformático no existe esto (al menos que yo conozca). No hay una entidad certificadora que garantice un nivel determinado de calidad. Bueno, sí hay estándares y cosas, pero todos sabemos cómo se cumplen ;) [...]
Según recuerdo Linux es un OS que por su construcción no es afectado por errores en las aplicaciones que se ejecutan sobre el. Aunque es una frase algo ligera, pues ya se han mencionado varios bugs existentes en los sistemas de archivos, que pueden causar problemas graves. =/ Nos acercamos peligrosamente a la paranoia. =P
Una pequeña aclaración: un sistema de ficheros es parte del kernel, no es una aplicación ;)
Si el usuario no tiene datos, no puede saber que hay un problema y no puede solucionarlo.
Pero si compras hardware (memoria RAM, por poner un ejemplo) malo y te falla (lo normal) ... ¿qué datos guardas si están todos corruptos o bien se han esfumado? Si la placa base es mala ... los datos que se transmiten pueden corromperse o bien un problema de tensión te puede dañar el disco de forma que NO puedes acceder al disco: ¿dónde guardo qué datos?
Ya, pero te das cuenta en el momento, lo cambias y listo. En cambio, un fallo del sistema de archivos que no escribe los datos porque se piensa que están escritos pero realmente no lo están (eso es lo que comentabas hace poco) pues te deja a dos velas: ademaś de perder datos, no sabes el alcance de esa pérdida, que puede hacerte que tengas que volver a instalar de nuevo porque el equipo se cuelga de manera inesperada (por ejemplo) cuando antes no lo hacía y no sabés el motivo (¿será por el problema que tuve al apagarlo a lo bruto aquél día o fallará la fuente, o quizá el disco duro tenga algún problema...?) ¡No sabes nada! Si al menos registrara los datos que elimina :-P
¿Un equipo que vigila el sistema central o que almacena los logs del sistema?
Syslog (y variantes -ng) permiten esto, lo malo es que si se produce un corte de luz ... no hay nada que loguear porque no hay datos. Si hay un cuelgue, el syslog no puede escribir porque se ha colgado el sistema :(
Alguien pregunto al respecto de eso hace un par de años creo... o fue el año pasado. Sin embargo cual es el problema, ¿tener un rápido diagnostico? o ¿no tener perdida de datos? solución vs consecuencia.
Bueno cabe insistir que de estos sistemas se poco o nada, sin embargo creo que esta discusión es nada nuevo y se ha presentado con anterioridad en otro lugar y en otro medio, por tanto debe de haber soluciones que, si bien no son perfectas, minimizan perdidas. Si alguien las conoce, que las mencione y si puede brindar algún enlace con la información, enhorabuena. Y si incluye el costo de estas, mejor aún.
Para minimizar péridadas o probabilidades, tienes SAI, redundancia, alta disponibilidad, disaster recovery, business continuance. [...]
=( Pero ya se mencionó lo del SAI y supongo que el sistema esta conectado al SAI y conoce cuanto jugo queda en caso de haber un corte de energía, se apagará adecuadamente y se grabará la información. Pero si el disco duro se "malea" de la nada. Pues hay sistemas contra eso ¿no?
Tienes RAID, pero no protege frente a todo. A parte de la pérdida de datos por la pérdida de caché, hay otro error que aparece en los discos duros (que no recuerdo cómo se llama) en el que un bit se cambia sólo (si era 1, pasa a 0 y a la inversa). Esto se debe a que son bloques inmantados muy sensibles y las corrientes eléctricas o campos electromagnéticos y pueden producir estos "flips" de bits. Si esto se produce una vez escrito el dato en el platter, el bit de paridad ya estaba escrito para el dato original por lo que el RAID no detecta estos errores ... volvemos a los CRCs, por ejemplo, para garantizar que el dato es el que se había escrito originariamente.
¿Qué tenemos, memoria ram? Pues que la usen, que el disco vuelque los datos a la ram (a modo de buffer) y que pueda recuperarlos y volver a escribirlos en disco antes de desecharlos y dejar el archivo a 0 bytes.
O.O? y si la memoria esta llena. =P Ya comenzamos a dar vueltas en circulo.
;)
No te digo hace 30 años, pero hoy en día, pues sí.
No digo que estés equivocada. Lo que digo es que no es tan fácil como te imaginas/piensas.
No, supongo que no lo es, pero merece la pena mejorar la seguridad de los datos.
Eso lo consideran ustedes los SysAdmins en el diseño de los sistema. ;P
Sí, pero el cliente o el jefe piensa^H^H^H^H^H^H opina que eso es muy caro y no se implementa y, al perder los datos, la culpa es nuestra.
Se avanza mucho en hardware pero poco en software :-(
IMHO, se avanza demasiado y se asienta (aka depura y profile) poco :( Es decir, se introducen demasiadas novedades (¿features?) sin asentar y depurar las que ya existen.
Sí, cierto. Hay mucha cantidad y poca calidad. Y lo que es peor, en algunos casos se pierden funcionalidades.
¿windows?
¿Cómo es que has pensado en Windows? ;) [...]
¿Hay algún log donde se pueda ver los accesos y cierres de archivos?
Que yo sepa no, puedes usar comandos como lsof o strace para ver qué ficheros se están usando. [...]
Las SSD basadas en DRAM tienen algunas ventajas.
Pero siguen DEPENDIENDO de la electricidad. Si falla la luz, es inmediato el fallo a menos que haya un HW por en medio que garantice cierta corriente (batería, por ejemplo). El sw no puede hacer nada porque es una capa superior que DEPENDE de las que hay abajo, por lo que si las de abajo fallan ... lo de arriba falla. Y si lo de abajo falla impredeciblemente ... lo de arriba no puede hacer nada.
Suspendes a ram o suspendes a "poner-aquí-X-componente-que-permita-almacenar-datos-para-luego-recueprar los" :-P
=P~ Nuevamente, ¿cuanto está dispuesto a pagar por esa solución? y recuerde que el espacio también cuesta.
Gracias por recordarlo, el espacio y el consumo son dos factore muy preocupante en los CPDs actualement :( [...]
Yo espero que no se hayan aburrido y creo que definiendo bien el problema y conociendo las soluciones que minimicen los problemas no harán hígado ni les explotará la cabeza cuando pierdan archivos. Tampoco les dará paro cuando les llegue la cuenta del mes. ;P
;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org