Tecnología

Tecnología en General

Publicación APIs

  • admin 

Publicación APIs

He estado revisando un poco el tema de cómo hacen los grandes para publicar sus APIs, y por lo que veo no hay una regla más o menos común.

Por lo que parece cada uno tiene su método para publicar sus APIs públicas en la web de una forma más o menos automatizada, de tal forma, que se genera un contenido estático que se puede consultar como referencia, supongo que bien a partir de unos ficheros de definición del API, o a partir del propio código.

Por ejemplo, uno de los APIs más extensamente documentados es el API REST de cloudfare:

  • API REST CLOUDFARE

https://api.cloudflare.com/

Todo el API viene documentado con ejemplos de solicitudes y respuestas, y las solicitudes vienen agrupadas por categorías. Lo que veo también es que las APIs van mutando conforme a sus necesidades, por lo que el servidor de APIs suele mantener las URLs antiguas, y las solicitudes se realizan siempre sobre una URL que dentro del árbol contiene la versión del API.

En el caso de cloudfare se ve que el proceso de publicación, si bien es automatizado, contiene texto explicativo para cada llamada así como ejemplos, lo que lleva a suponer que igual se genera automáticamente a partir de la documentación contenida dentro del propio código que la soporta.

  • API KUBERNETES

Otro de los ejemplos de APIs REST extensamente documentados en la web es el API de Kubernetes:

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/

La documentación de este API, como su propio nombre dice en la URL, está «generado». Escarbando un poco más vemos que utiliza el swagger para definir y documentar las APIs:

https://kubernetes.io/docs/concepts/overview/kubernetes-api/

Según comenta en el link de arriba, las APIs son documentadas y expuestas directamente a través del servidor de APIs utilizando los documentos de especificación openAPI con el swagger. Se da la circunstancia de que kubernetes facilita herramientas al administrador del sistema que permiten generar y modificar APIs adhoc para gestionar su plataforma de contenedores a medida. Dichas APIs se generan por linea de comando y almacenan de forma serializada en el servidor de APIs para poder ser publicadas y expuestas por el servidor conforme se van generando y/o modificando. Hay otro link en un foro que habla sobre el tema aquí:

https://thenewstack.io/taking-kubernetes-api-spin/

  • APIS GENERADAS SOLUCION SPRING BOOT

En otro link se comenta una solución para publicar en base a los ficheros openAPI las APIs generadas para una solución de software llamada spring boot:

https://keyholesoftware.com/2017/03/28/auto-publishing-monitoring-apis-with-spring-boot/

Como curiosidad, el propio kubernetes utiliza un API alternativo basado en el protocol buffers desarrollado por google, y que utilizan extensivamente las plataformas de microservicios desplegadas bajo demanda en la nube. Aquí aparece la justificación de la migración del API al nuevo formato, por motivos de escalabilidad y simplicidad, principalmente.

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md

En el caso de Go se utiliza una librería llamada gogo-protobuff mucho más eficiente a efectos de rendimiento en la serialización/deserialización que la librería nativa de google. Esta es la página del proyecto donde aparecen también algunas de las empresas que la usan, entre ellas Cloudfare:

https://github.com/gogo/protobuf

Como veis el tema de la optimización y gestión de APIs es un problema recurrente.

  • DOCUMENTACION APIS POR GOOGLE

Este es el enfoque utilizado por Google para su API de gestión de cloud:

https://cloud.google.com/apis/design/proto3

https://developers.google.com/protocol-buffers/

Aquí tienen publicada en github las APIs, en un repositorio:

https://github.com/googleapis/googleapis

Los ficheros de entrada son los protobuff, y también ficheros YAML. Con esos ficheros utilizan una herramienta llamada Artman para generar y publicar las APIs:

https://github.com/googleapis/artman

Al generar y publicar las modificaciones de las APIs automáticamente mediante el repositorio GIT, utilizan una sistema de integración continua (en este caso en lugar de Travis utilizan Circle) para ver los resultados de las pruebas:

https://circleci.com/gh/googleapis/googleapis

Pues eso, que cada maestrillo tiene su librillo, pero la cosa se resume en que se utiliza un lenguaje para especificar los mensajes petición/respuesta del API, y este se compila tanto para generar las funciones de serialización/deserialización de los mensajes, como para publicarlo y hacerle las pruebas de regresión, etc… con el fin de que un cambio en la especificación no rompa nada en los servicios que están en producción. La apuesta de Google por la cosa esta es que tiene unos 48000 y pico mensajes en más de 12000 APIs para gestionar todos sus servicios internos, y mantener y escalar todo eso se convertía en un infierno, por eso hace unos 5 años empezaron a apostar por el proyecto y a migrar todo internamente al nuevo formato de encapsulación de datos. En este link aparece un poco de historia y explica bastante bien los motivos que les condujeron a adoptar esa solución:

https://developers.google.com/protocol-buffers/docs/overview

Como podéis ver la generación de los ficheros proto para los mensajes es bastante sencilla, y eso es precisamente lo que andaba buscando la gente de Google, enfocarse en la parte de la lógica del microservicio y dejar a la capa de transporte en un plano aparte con un problema resuelto.

Aplicado al caso práctico con el swagger: supongo que si el kubernetes tiene la posibilidad de publicar en el servidor de APIs los ficheros openAPI generados usando el swagger, debe de haber alguna forma de mantener en un repositorio git los ficheros YAML o JSON con las especificaciones openAPI, y en el swagger configurar el directorio con la versión actualizada de los ficheros del repo para poder publicarlo directamente a través del puerto.

Es decir, que haces un commit sobre el repositorio git, y se lanza un webhook (o periódicamente por crontab) un proceso para clonar la ultima versión de las APIs sobre el directorio del que se alimenta el swagger para publicar las APIs. El tema de probar las APIs ya es cosa de hacerlo en un servidor de integración continua sobre un entorno de pruebas y publicar los resultados.

Clustering Mysql con Vitess

  • admin 

Clustering Mysql con Vitess

Viendo algunos de los proyectos con Golang que utilizan en Google, este me ha llamado la atención, porque es lo que utilizan desde 2011 con Youtube para mantener la BBDD de Mysql en cluster:

http://vitess.io/

https://github.com/youtube/vitess/

Entre sus funcionalidades, no solo mantiene el tema de la replicación y el shardening entre los nodos (en Youtube son decenas de miles de nodos con MySQL), sino que optimiza las operaciones que pueden sobrecargar la BBDD así como el uso de la caché, la gestión de los backups, etc…

Mirmon monitoriza repositorios replicados

Mirmon monitoriza repositorios replicados

Hay una herramienta opensource para la monitorización de los repositorios replicados (mirrors) de forma distribuida. Se llama mirmon:

http://www.staff.science.uu.nl/~penni101/mirmon/

La cosa es que tiene un uso bastante extendido en los proyectos opensource populares. Aquí tenenos un ejemplo de los mirrors del XBMC:

http://mirrors.xbmc.org/mirmon.html

Para los repositorios CPAN:

http://mirrors.cpan.org/

No está mal la herramienta.

Tutoriales Sips Interesantes

  • admin 

Tutoriales Sips Interesantes 

En la página web personal de Jonathan Rosenberg (el padre de las RFCs de SIP, SIMPLE, STUN, ICE, etc…), vienen varios tutoriales y presentaciones sobre VoIP, que pueden estar muy bien para hacerse una idea rápida sobre la materia, explicando detalles interesantes en algunos temas.

http://www.jdrosen.net/

La parte de tutoriales y presentaciones no tiene desperdicio:

http://www.jdrosen.net/tutorials.html

Guía uso Iperf

  • admin 

Guía Uso Iperf

Iperf es una herramienta muy útil para comprobar el ancho de banda real de conexión disponible. Tanto para Unix y/o Windows.

Iperf puede configurarse en 2 modos:

  • Modo Servidor
  • Modo Cliente.

El host en modo iperf servidor escucha conexiones remotas originadas desde potenciales host iperf cliente. El host iperf cliente define los parámetros de test de ancho de banda, y se conecta al servidor remoto.

 

  • Instalación iperf.

apt-get install iperf

 

  • Iniciar servidor iperf.

iperf -s

root@smokeping1:/# iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————

 

  • Arrancar servidor iperf como demonio.

Se puede arrancar el servidor manual, o como demonio. Para este segundo caso se debe añadir el parámetro -D (se ejecuta iperf como demonio en background).

iperf -s -D

iperf -s -D > /var/log/iperf-log.log

root@server:/home/ubuntu# iperf -s -D > /var/log/iperf-log.log
Running Iperf Server as a daemon
The Iperf daemon process ID : 3546
root@server:/home/ubuntu#

  • Conectar un host iperf client a un host iperf servidor

Iperfs necesita ejecutarse en el host local en modo cliente, así como en el servidor remoto en modo servidor. Se debe explicitar la ip con el argument -c.

iperf -c ip_servidor.

[root@fc18-atica ~]# iperf -c 112.131.5.76
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 85.0 KByte (default)
————————————————————
[ 3] local 10.134.16.230 port 51345 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-13.4 sec 7.75 MBytes 4.85 Mbits/sec
[root@fc18-atica ~]#

 

  • Duración del Test (por defecto 10).

La duración por defecto es 10. Se puede explicitar una duración mayor con el argumento t.

iperf -c ipserver -t 60 (duración 60 sgs).

root@observium:/etc# iperf -c 112.131.5.76 -t 3    (duración total de 3sgs).
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 23.5 KByte (default)
————————————————————
[ 3] local 172.0.0.14 port 44967 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 3.0 sec 323 MBytes 902 Mbits/sec
root@observium:/etc#

 

  • Intervalo de tiempo durante el que se mide (ancho de banda, jitter, y packet loss).

Por defecto es cero. En este caso hay un único reporte.

iperf -c ip_server -i 2

root@observium:/etc# iperf -c 112.131.5.76 -t 6 -i1
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 23.5 KByte (default)
————————————————————
[ 3] local 172.0.0.14 port 44968 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 99.6 MBytes 836 Mbits/sec
[ 3] 1.0- 2.0 sec 102 MBytes 851 Mbits/sec
[ 3] 2.0- 3.0 sec 102 MBytes 854 Mbits/sec
[ 3] 3.0- 4.0 sec 102 MBytes 856 Mbits/sec
[ 3] 4.0- 5.0 sec 102 MBytes 860 Mbits/sec
[ 3] 5.0- 6.0 sec 102 MBytes 852 Mbits/sec
[ 3] 0.0- 6.0 sec 609 MBytes 851 Mbits/sec
root@observium:/etc#

 

  • Conexión bidireccional.

Se comprueba la velocidad en un sentido y luego en el otro.

Se utiliza el argumento r para comprobar la dirección en un sentido y luego en el otro. Primero desde el servidor al cliente y luego en sentido contrario. Con el argumento d sería el orden al revés.

iperf -c ip_servidor -r .

 

  • Cambiar protocolo udp en lugar tcp.

Por defecto Iperf usa TCP. Si se desea utilizar UDP debe utilizarse tanto en el servidor como en el cliente el argumento u.

iperf -c ip_server -u

iperf -s -u

El resultado contendrá una métrica extra para el packet loss. Esta debe ser lo más pequeña posible como es natural.

 

  • Lanzar múltiples threads

  • Comprobar la versión de Iperf

Se utiliza el argumento v para comprobar la versión del iperf.

root@server:/home/ubuntu# iperf -v
iperf version 2.0.5 (08 Jul 2010) pthreads

  • Ayuda Iperf.

Se utiliza el argumento h para comprobar toda la lista de argumentos soportados por iperf.

Crash 512K Internet

  • admin 

Crash 512K Internet

#512K

En relación con el problemón que ha habido con el tamaño de las entradas de prefijos en los routers BGP #512K (pasado 12 agosto), estos son los comandos útiles para ver el tema de las entradas en la TCAM en los routers BGP:

1) Con esto vemos el dimensionado de las entradas:

BGP_sp_mad_C01#sh mls cef maximum-routes FIB TCAM maximum routes :

=======================

Current :-

——-

IPv4               – 768k

MPLS               – 32k

IPv6 + IP Multicast – 112k (default)

2) Con esto podemos saber que es lo que está consumiendo actualmente:

BGP_sp_mad_C01#sh mls cef summary

Total routes:                     507123

IPv4 unicast routes:         507110

IPv4 Multicast routes:       3

MPLS routes:                 1

IPv6 unicast routes:         9

IPv6 multicast routes:       0

EoM routes:                   0

3) Con esto podemos averiguar si en algún momento el router ha sobrepasado alguno de los límites configurados en el hardware:

BGP_sp_mad_C01#sh mls cef exception status Current IPv4 FIB exception state = FALSE Current IPv6 FIB exception state = FALSE Current MPLS FIB exception state = FALSE

4) Por último (pero no menos importante), con este comando tenemos información detallada de las capacidades de cada procesadora (con picos de tráfico por tarjeta, etc…):

BGP_sp_mad_C01#sh platform hardware capacity System Resources

PFC operating mode: PFC3CXL

Supervisor redundancy mode: administratively sso, operationally sso

Switching resources: Module   Part number               Series     CEF mode

1       7600-SIP-400             CEF256           CEF

2       7600-SIP-400             CEF256           CEF

3       WS-X6704-10GE             CEF720           CEF

4       WS-X6704-10GE             CEF720           CEF

5       RSP720-3CXL-GE       supervisor           CEF

6       RSP720-3CXL-GE       supervisor           CEF

Power Resources

Power supply redundancy mode: administratively redundant

operationally redundant

System power: 2669W, 0W (0%) inline, 1981W (74%) total allocated

Powered devices: 0 total, 0 Class3, 0 Class2, 0 Class1, 0 Class0, 0 Cisco

Flash/NVRAM Resources

Usage: Module Device               Bytes:     Total         Used     %Used

3     dfc#3-bootflash:             32768000             0       0%

4     dfc#4-bootflash:             32768000             0       0%

5 SP sup-bootdisk:               518799360     181633024       35%

5 SP const_nvram:                   127212           736       1%

5 SP nvram:                         4059328         42536       1%

5 RP bootdisk:                   518799360             0       0%

6     slavenvram:                  4059328         42536       1%

6     slaveconst_nvram:               127212           736       1%

6     slavesup-bootdisk:           512090112     153755648       30%

6     slavebootdisk:               512090112             0       0%

CPU Resources

CPU utilization: Module             5 seconds       1 minute       5 minutes

3                   0% / 0%             0%              0%

4                   0% / 0%             0%             0%

5 RP               2% / 1%             7%             7%

5 SP             11% / 4%           17%             16%

6 RP               0% / 0%             0%             0%

6 SP             10% / 3%           13%             11%

Processor memory: Module   Bytes:       Total           Used           %Used

3                 199560096       44738032             22%

4                 199560096       44738036             22%

5 RP           1767501440     703985232             40%

5 SP           697855300     325334884             47%

6 RP           1767501440     224678068             13%

6 SP             670689728     296054500             44%

I/O memory: Module         Bytes:       Total          Used           %Used

5 RP                   134217728       39163552             29%

5 SP                   67108864       34114152             51%

6 RP                   134217728       39163552            29%

6 SP                   67108864       34114152             51%

EOBC Resources

Module                     Packets/sec     Total packets     Dropped packets

3         Rx:                     11           8467346                   0

Tx:                       5           871269                   0

4         Rx:                     12           8463915                   0

Tx:                       6           871425                  0

5 RP     Rx:                     81           5595544                   0

Tx:                     49           4916667                   0

5 SP     Rx:                     23           2867868                   0

Tx:                     31           3247413                   0

6 RP     Rx:                       0           204837                   0

Tx:                       0           180449                   0

6 SP     Rx:                     11           624649                   0

Tx:                     10           493665                   0

VLAN Resources

VLANs: 4094 total, 8 VTP, 0 extended, 35 internal, 4051 free

L2 Forwarding Resources

MAC Table usage:   Module Collisions Total       Used       %Used

5               0 98304         29         1%

6               0 98304         29         1%

VPN CAM usage:                       Total       Used       %Used

512         0         0%

L3 Forwarding Resources

Module             FIB TCAM usage:                     Total       Used     %Used

5                     72 bits (IPv4, MPLS, EoM)     819200     507165     62%

144 bits (IP mcast, IPv6)     114688           12     1%

detail:     Protocol                  Used       %Used

IPv4                     507164         62%

MPLS                           1         1%

EoM                           0         0%

IPv6                           9         1%

IPv4 mcast                     3         1%

IPv6 mcast                     0         0%

Adjacency usage:                     Total       Used       %Used

1048576         461         1%

Forwarding engine load:

Module       pps   peak-pps                     peak-time

5         526897     616731 12:52:18 Europe/ Wed Aug 13 2014

6         525469     617711 12:52:13 Europe/ Wed Aug 13 2014

Switch Fabric Resources

Bus utilization: current: 1%, peak was 1% at 15:55:24 Europe/ Wed Aug 13 2014

Fabric utilization:     Ingress                   Egress

Module Chanl Speed rate peak                 rate peak

1       0       20G   0%   5% @03:42 13Aug14   0%   1% @02:27 13Aug14

2       0       20G   1%   4% @13:38 13Aug14   0%   5% @04:03 13Aug14

3       0       20G   2%   5% @09:39 13Aug14   2%   4% @03:07 13Aug14

3      1       20G   3%   13% @15:50 13Aug14   2%   6% @10:52 13Aug14

4       0       20G   1%   2% @11:59 13Aug14   0%   2% @03:12 13Aug14

4       1       20G   1%   4% @10:52 13Aug14   3%   12% @15:50 13Aug14

5       0       20G  1%   2% @02:27 13Aug14   3%   5% @09:36 13Aug14

6       0         8G   2%   6% @09:19 13Aug14   3%   9% @09:36 13Aug14

 

… vamos, que no tiene desperdicio el comando.

SATA II comparado a SATA III

  • admin 

SATA II comparado a SATA III

  • SATA I (1.x revisión) interfaz, formalmente conocida como SATA 1.5 GB/s, es la primera generación de la interfaz SATA funcionando a1,5GB/s. El rendimiento de ancho de banda, que es soportado por la interfaz, es de hasta 150MB/s.

 

  • SATA II (versión 2.x) interfaz, formalmente conocida como SATA 3 GB/s, es la segunda generación de la interfaz SATA funcionando a3,0GB/s. El rendimiento de ancho de banda, que es soportado por la interfaz, es de hasta 300MB/s.

 

  • SATA III (versión 3.x) interfaz, formalmente conocida como SATA 6GB/s, es la tercera generación de la interfaz SATA funcionando a6.0GB/s. El rendimiento de ancho de banda, que es sopotado por la interfaz, es de hasta 600MB/s. Esta interfaz es compatible con lainterfaz de 3 GB/s SATA.

Las especificaciones SATA II proporcionan compatibilidad para funcionar en los puertos SATA I.
Las especificaciones SATA III proporcionan compatibilidad con versiones anteriores para funcionar en los puertos SATA II y SATA I. Sin embargo, la velocidad máxima de la unidad será más lenta debido a las limitaciones de velocidad del puerto.

Resumiendo, las mejoras que introduce el SATA III, frente a sus antecesores son:

  • Mejora de velocidad de transferencia
  • Nuevo comando NCQ que permite la transferencia de datos asíncrona para mejorar el ancho de banda, beneficiando los sistemas de streaming de audio y video.
  • Capacidades mejoradas para el control de sistemas de ahorro de energía
  • Nuevo diseño de conectores para dar soporte a dispositivos de menores dimensiones. Hay conectores más pequeños, pensados sobre todo para unidades de 1.8” y para pequeños PCs, tablets y semejantes.
  • Compatibilidad con anteriores versiones del estándar SATA

 

Tipos de Discos Duros

  • admin 

Tipos de Discos Duros

Si atendemos al tipo de conexión, pueden ser IDE,SCSI,SATA o SAS:
IDE: Integrated Drive Electronics («Dispositivo electrónico integrado») o ATA (Advanced Technology Attachment), controla los dispositivos de almacenamiento masivo de datos, como los discos duros y ATAPI (Advanced Technology Attachment Packet Interface) Hasta aproximadamente el 2004, el estándar principal por su versatilidad y asequibilidad. Son planos, anchos y alargados.

SCSI: Son interfaces preparadas para discos duros de gran capacidad de almacenamiento y velocidad de rotación. Se presentan bajo tres especificaciones: SCSI Estándar (Standard SCSI), SCSI Rápido (Fast SCSI) y SCSI Ancho-Rápido (Fast-Wide SCSI). Su tiempo medio de acceso puede llegar a 7 milisegundos y su velocidad de transmisión secuencial de información puede alcanzar teóricamente los 5 Mbit/s en los discos SCSI Estándares, los 10 Mbit/s en los discos SCSI Rápidos y los 20 Mbit/s en los discos SCSI Anchos-Rápidos (SCSI-2). Un controlador SCSI puede manejar hasta 7 discos duros SCSI (o 7 periféricos SCSI) con conexión tipo margarita (daisy-chain). A diferencia de los discos IDE, pueden trabajar asincrónicamente con relación al microprocesador, lo que posibilita una mayor velocidad de transferencia.

SATA (Serial ATA): El más novedoso de los estándares de conexión, utiliza un bus serie para la transmisión de datos. Notablemente más rápido y eficiente que IDE. Existen tres versiones, SATA 1 con velocidad de transferencia de hasta 150 MB/s (hoy día descatalogado), SATA 2 de hasta 300 MB/s, el más extendido en la actualidad; y por último SATA 3 de hasta 600 MB/s el cual se está empezando a hacer hueco en el mercado. Físicamente es mucho más pequeño y cómodo que los IDE, además de permitir conexión en caliente.

SAS (Serial Attached SCSI): Interfaz de transferencia de datos en serie, sucesor del SCSI paralelo, aunque sigue utilizando comandos SCSI para interaccionar con los dispositivos SAS. Aumenta la velocidad y permite la conexión y desconexión en caliente. Una de las principales características es que aumenta la velocidad de transferencia al aumentar el número de dispositivos conectados, es decir, puede gestionar una tasa de transferencia constante para cada dispositivo conectado, además de terminar con la limitación de 16 dispositivos existente en SCSI, es por ello que se vaticina que la tecnología SAS irá reemplazando a su predecesora SCSI. Además, el conector es el mismo que en la interfaz SATA y permite utilizar estos discos duros, para aplicaciones con menos necesidad de velocidad, ahorrando costes. Por lo tanto, las unidades SATA pueden ser utilizadas por controladoras SAS pero no a la inversa, una controladora SATA no reconoce discos SAS.

La preferencia más profesional (y más cara) será por discos duros SAS. En la siguiente tabla se muestra una comparativa interesante.

Fuente: http://www.intel.com/support/sp/motherboards/server/sb/cs-031831.htm

Requisito

SAS

SATA

Disponibilidad operativa

Las 24 horas del día, 7 días a la semana

8 Horas/día – 5 días a la semana

Carga

100%

10 – 20%

Sensibilidad de los costos

Moderadamente sensible al costo

SENSIBLES a bajo costo

Desempeño

La latencia y buscan

@ 15K rpm de 5,7 ms

13 ms @ 7200 rpm (o más pequeños)

Cola de comandos y Reordenación

Completo

Limitada

Tolerancia a Vibración Rotacional

Hasta 21 Rad/seg/seg

Hasta 5 a 12 Rad/seg/seg

Típica E/S por seg/unidad

319

77

Operación dúplex

Completo

Media

Confiabilidad

Bad sector recuperación

Tiempo típico entre 7-15 seg sólo

Leyendas el Tiempo hasta 30 seg

Detección de La desalineación

Servo dedicados y los procesadores de ruta de datos

Único combinado/datos servo de procesador o ninguna ruta

La Vibración Sensores

RV compensación mecanismo de Retroalimentación

Ninguna compensación RV

Variable Tamaño de sector

Utiliza un sector de 528 bytes y permita que el controlador de E/S

No utilizan un sector variable (tamaño combinado con 512 bytes)

MTBF

1,2 M horas a 45 grados C

700K horas a 25 grados C

Comprobaciones de integridad interna de datos

Extremo a extremo

Limitada, ninguno en la memoria búfer

Temperatura máxima de operación

~60 grados C

Aproximadamente 40 grados C

Garantía

~5 Años

~ a 3 años

Características

Motor bandeja giratoria

Superior RPM
Ejecutar más reducidos de salida
anclaje bandeja giratoria en ambos extremos

Moderar para reducir RPM
La especificación inferior para ejecutar-out
Bandeja giratoria haya fijado en un extremo

Medios

Cert completa de medios

La especificación y menor densidad medios

Cabeza pila ensamblaje

rigidez estructural
Diseño inercial menor

Diseño más liviano peso
Diseño de superior inercial

Accionador mecánica

imanes más grandes
Turbulencia de aire controles
Los sensores de lazo cerrado y RV RV
Supresión

imanes más pequeñas
Ninguna compensación de turbulencia de aire
No hay sensores de RV o supresión – limitadas a
Alineación del servo track de cuña

Electrónica

Los procesadores de doble
Los procesadores dedicados (servo y datos de ruta de acceso)
Optimización del desempeño
Manejo de errores avanzada
Firmware avanzados algoritmos

Solo procesador

Ninguna optimización de rendimiento
Manejo de errores estándar
Los algoritmos estándar Firmware

Personalización

FW Código

Amplio

Limitada

Variable sector tamaños

No

LED

No

 

Tipos de RAID Almacenamiento

  • admin 

Tipos de RAID Almacenamiento

Hay  12 tipos o variedades distintas de RAID disponibles en el mercado (y aún son más las que se han desarrollado). Sin embargo, para la gran mayoría de pequeñas y medianas empresas (PyME), sólo hay seis niveles RAID realmente relevantes. Elegir el nivel RAID adecuado dependerá del tipo de datos de las aplicaciones, del nivel de relevancia de esos datos y del número de usuarios.

RAID 0

Una RAID 0 divide o reparte los datos entre todas las unidades del grupo RAID. La ventaja de la RAID  es que ofrece un mayor rendimiento de los datos. El inconveniente es carecer de redundancia. Cualquier avería de algún disco origina una pérdida total de los datos.

RAID 0 es la mejor opción cuando es primordial obtener un mayor rendimiento del almacenamiento, cuando el presupuesto es muy limitado y cuando una posible pérdida de los datos no supone mayor problema.

Por ejemplo, algunos datos que funcionan bien en este nivel son los archivos temporales de edición de fotografía o vídeo.

RAID 1

Una RAID 1 duplica en espejo todos los datos de cada unidad de forma sincronizada a una unidad de duplicación exacta. Si se produce algún fallo o avería en alguna de las unidades, no se pierde ningún dato.

La ventaja de utilizar una RAID 1 es disponer de un mayor rendimiento de lectura multiusuario, puesto que pueden leerse ambos discos al mismo tiempo.

La desventaja es que el costo de la unidad de almacenamiento por byte usable se multiplica por dos, puesto que se necesitan dos unidades para almacenar los mismos datos.

Elija una RAID 1 para aplicaciones que requieran de una “red de seguridad” (es decir, cuando no pueda permitirse la posibilidad de que se pierdan o estropeen los datos de la aplicación) además de lecturas aleatorias de alto rendimiento. Un buen ejemplo para este tipo de RAID puede ser la base de datos de sólo lectura de una tienda de venta al por menor no virtual. Una RAID 1 también es una buena elección  para sistemas de nivel básico en los que sólo están disponibles dos unidades, como en el caso de un pequeño servidor de archivos.

RAID 10 (es decir, RAID 1+0 y RAID 0+1)

Una RAID 10 es la combinación de una RAID 0 y una RAID 1. La ventaja de utilizar una RAID 10 es disponer de la redundancia de la RAID 1 y del nivel de rendimiento de la RAID 0.

El rendimiento del sistema durante la reconstrucción de una unidad también es sensiblemente superior en comparación con los niveles RAID basados en paridad (es decir, la RAID 5 y la RAID 6). Esto se debe al hecho de que los datos no necesitan realizar procesos de regeneración de la información de la paridad porque ésta se copia de la otra unidad replicada. El inconveniente es el costo, muy superior (normalmente, entre un 60 y un 80% más caro) al de los niveles RAID con paridad.

Hay dos tipos de RAID 10. El primero es la RAID 0+1, en la que se dividen los datos entre múltiples discos y, después, se duplican en espejo los discos distribuidos en un grupo de discos idéntico. La segunda clase es la RAID de nivel 1+0, que duplica en espejo los datos en los casos en los que las réplicas se han distribuido entre distintas unidades.

Debería decantarse por las RAID 10 cuando utilice aplicaciones que requieran del alto rendimiento de una RAID 0 y de la incomparable protección de los datos que ofrece una RAID 1. Las bases de datos transaccionales en línea suelen encajar en este perfil.

RAID 5

La RAID 5 está diseñada para ofrecer el nivel de rendimiento de una RAID 0 con una redundancia más económica y es el nivel RAID más habitual en la mayoría de empresas. Lo consigue distribuyendo bloques de datos entre distintas unidades y repartiendo la paridad entre ellas. No se dedica ningún disco a la paridad de forma exclusiva. Las ventajas de utilizar una RAID 5 consisten en poder realizar operaciones de lectura y escritura de forma solapada (es decir, en poder hacer un uso más eficiente de las unidades de disco), lo que acelera los pequeños procesos de escritura en un sistema multiprocesador y facilita una cantidad de almacenamiento usable superior al de la RAID 1 o 10 (dado que la redundancia acarrea una reducción del almacenamiento de, aproximadamente, el 20%, en vez del 50%). La protección de los datos reside en la información de la paridad que se utiliza para reconstruir los datos si una unidad del grupo RAID falla o sufre una avería. Entre los inconvenientes, se encuentran: la necesidad de un mínimo de tres (y, normalmente, cinco) discos por grupo RAID, un nivel de rendimiento del sistema de almacenamiento significativamente inferior mientras se lleva a cabo la reconstrucción de una unidad, y la posibilidad de peDRer totalmente los datos de un grupo RAID si falla una segunda unidad mientras se está realizando la reconstrucción de la primera. Además, el rendimiento de lectura suele ser inferior al de otras modalidades de RAID porque los datos de la paridad se distribuyen entre cada una de las unidades.

Debería decantarse por una RAID 5 para la gran mayoría de aplicaciones, siempre y cuando las unidades de disco no sean unidades SATA de gran capacidad. Las unidades SATA tienen ciclos de trabajo más cortos que las unidades SAS o de canal de fibra, e índices MTBF inferiores. Y, dado que las unidades SATA tienen una gran capacidad (de 500 a 1000 GB), los tiempos de reconstrucción son muy largos y conllevan una degradación del rendimiento del controlador. Las unidades SATA de gran capacidad también aumentan la probabilidad de que se produzca un fallo o avería en una segunda unidad, lo que ocasionaría una pérdida total de los datos.

RAID 6

La RAID 6 es similar a la RAID 5 e incluye un segundo sistema de paridad distribuido entre las unidades del grupo RAID. La ventaja de utilizar una RAID 6 es que la segunda paridad sirve de protección ante una posible péDRida de los datos en caso de que falle o se averíe una segunda unidad dentro del grupo RAID. Esto hace que las unidades SATA de gran capacidad sean más viables y económicas que la RAID 1 o la RAID 10. El inconveniente de utilizar una RAID 6 es que se obtiene un nivel de rendimiento del sistema de almacenamiento mucho menor cuando se está llevando a cabo la reconstrucción de dos unidades de forma simultánea (normalmente, por debajo del 20%).

Debería decantarse por una RAID 6 en el caso de unidades SATA de gran capacidad y aplicaciones que puedan tolerar un nivel de rendimiento reducido en ciertas ocasiones. Algunas aplicaciones que encajan en este perfil son los archivos de datos multimedia no dinámicos como los JPEGs y el vídeo en streaming.

RAID 50 (también conocida como RAID 5+0 y RAID 0+5)

La RAID 50 es la combinación de una RAID 0 y una RAID 5. Toma grupos RAID 5 y los distribuye como si fueran RAID 0, lo que aumenta el nivel de rendimiento. La ventaja de la RAID 50 es su mayor rendimiento en comparación con la RAID 5 estándar. Las desventajas son su mayor costo y que tiene menos capacidad usable.

Existen dos variedades de RAID 50. La RAID 0+5 utiliza múltiples grupos de RAID 5 distribuidos en un solo grupo RAID. Esto hace que la fiabilidad del grupo RAID aumente, ya que, ahora, puede tolerar que una unidad falle o se averíe en uno o en ambos conjuntos de RAID 5 sin que se pieDRan los datos. La RAID 5+0, la RAID 50 más habitual, toma grupos de RAID 5 y los distribuye como si fueran RAID 0. Debería decantarse por la RAID 50 para aplicaciones en las que sea importante el ahorro económico de las RAID 5 y en las que también se necesite un mejor rendimiento.

 

Fuente: http://searchdatacenter.techtarget.com/es/consejo/Tutorial-RAID-como-elegir-el-nivel-RAID-adecuado

Passwordless SSH

  • admin 

Passwordless SSH can be accomplished using SSH’s public key authentication. To configure passwordless SSH, follow the directions below. Warning: passwordless SSH will make your systems less secure. If you are comfortable with that, the directions below will walk you through server and client configurations. Then, I’ll show you how to debug SSH if you encounter problems.

SSHD Server Configuration

First, you must ensure that your SSHD server allows for passwordless authentication using public keys. If you do not have root access to the server, do not worry. By default, public key authentication over protocol 2 is enabled. Skip this step. If you have any problems, contact your System Administrator.

If you have root privileges, edit your system’s /etc/ssh/sshd_config and apply the following settings. I suggest you disable protocol 1 RSA key based authentication and leave all other settings alone for now. Visit the man page SSHD_CONFIG(5) for details.

# Disable protocol 1 RSA key based authentication
RSAAuthentication no
# Protocol 2 public key based authentication
PubkeyAuthentication yes
# Authorized public keys file
AuthorizedKeysFile .ssh/authorized_keys

If you make any changes, save them and restart your SSH server.

service sshd restart

SSH Client Configuration

Now that the server is configured, log into your client system and examine /etc/ssh/ssh_config. This is the SSH client configuration file and you do not need to edit it.

less /etc/ssh/ssh_config

By default, public key authentication over protocol 2 is enabled for clients. You only need to make sure that it is not disabled. If it is, create an ~/.ssh/config to override the /etc/ssh/ssh_config options.

cp -a /etc/ssh/ssh_config ~/.ssh/config

Then edit it and add this to the «Host *» block:

PubkeyAuthentication yes

Create Client Key

With the client in order, you need to create a public and private key pair. The following command will build a DSA key pair. Hit for all questions asked. This will create a DSA key pair in ~/.ssh/. The private key is called id_dsa and the public key is id_dsa.pub.

ssh-keygen -t dsa

Use Key for Authentication

Now that you have a public and private key pair, put the public key on the server you wish to log into without a password. You will need to put the public key inside the server’s /home/user/.ssh/authorized_keys file. This file can contain multiple keys, so you generally do not want to just copy over it. Note that the authorized_keys2 file was deprecated in OpenSSH 3.0 (2001).

cat ~/.ssh/id_dsa.pub | ssh user@server "cat - >> ~/.ssh/authorized_keys"

Alternatively, modern releases of SSH have a command to help you copy keys.

ssh-copy-id -i ~/.ssh/id_dsa.pub user@server

Test and Debug SSH

Now, test.

ssh username@server date

If you get prompted for a password, check the server’s system logs for clues. You can also enable debugging in /etc/ssh/sshd_config with the following directive.

LogLevel DEBUG

Other options are INFO, VERBOSE, DEBUG2 and DEBUG3. See the man page SSHD_CONFIG(5) for details. For the client, the exact same option can be placed inside a /etc/ssh/ssh_config’s Host block. See SSH_CONFIG(5) for client debugging details.

man 5 sshd_config
man 5 ssh_config

 

Fuente: http://hacktux.com/passwordless/ssh