Pareciera que a donde mire, todos los chicos cool están hablando de la maravilla que es tener una red domestica a 10 Gb/s, basta fijarse en los resultados de YouTube cuando uno busca “10 Gigabit”:
10 Gigabit Ethernet hoy
Si bien 10 Gigabit Ethernet existe como estándar desde 2002 (con la ratificación de 802.3ae 17 años atrás, o sea, una eternidad), la realidad es que no se ha movido mucho fuera del mercado datacenter.
10GbE ya no es mas aquella vedette del networking dado que existen soluciones de 40Gbps y 100Gbps que tienen mucho mas sentido y por lo tanto esta apareciendo equipamiento 10GbE usado, lo suficientemente barato como para que YouTubers con plata entusiastas se tiren a probar 10GbE.
Para aquellos que no les gusta comprar usado, también están apareciendo soluciones de bajo costo, como el MikroTik CRS305-1G-4S+IN, a USD 149 (en origen, sumale envío y la usura de aduanas si vos también estas en Uruguay)
Lista de compras
Esta muy copado esto de 10Gbps pero que uso podemos darle realmente dentro del hogar? Nada de cosas, vamos a ver primero en que podemos quemar el dinero y dejamos las excusas para después.
Supongamos que fuera a comprar todo lo necesario para probar esto de 10GbE, con el objetivo de conectar la PC de escritorio con el servidor que esta a 2 o 3 metros de distancia, dejando el resto de la red como esta, a 1Gbps.
Acá es donde se empieza a complicar, porque tenemos varias opciones y el precio varia considerablemente.
Uno pensaría que la opción mas simple y económica seria la de usar 10Gbps sobre cable UTP CAT6a (10GBASE-T, o sea el cobre de toda la vida). Sin embargo, por el costo de una placa PCI-E 10GBase-T se puede conseguir una placa con dos jaulas SPF+ y un modulo, lo cual deja abierta la posibilidad de agregar un segundo modulo en el futuro sin tener que cambiar nada.
(A esto sumale el hecho que muchos vendedores lamentablemente no saben lo que es el CAT6A, no lo importan o te quieren vender una mentira llamada CAT6e)
Pero ademas, por menos de lo que cuestan 2 modulos SPF+ y el patchcord de fibra podemos ir por un DAC (“direct attach cable“). Al momento que escribo esto, estaríamos hablando de USD 14,99 vs. USD 50,99. Para distancias cortas, la opción DAC es la mas económica:
Si nuestro objetivo es simplemente agregar un enlace de 10Gbps entre dos equipos, ya tenemos todo lo necesario para salir a comprar, nuestras dos opciones siendo:
- CAT6a: patchcord + 2x placas de red = aprox. USD 200
- Direct-Attach SFP+: DAC + 2x placas de red = aprox. USD 153
Pero, podemos ir mas allá y en lugar de agregar un enlace, mejorar la conexión actual de 1Gbps a 10Gbps. Para esto, vamos a precisar comprar un switch.
Una opción siendo el MikroTik CRS305-1G-4S+IN mencionado al principio, cuesta unos USD 149 pero tiene la desventaja que nos limita a un solo uplink de 1Gbps para ambos equipos.
Otra opción seria algo como el Netgear GS110MX, que cuenta con 2 interfaces 10GBASE-T y 8 interfaces 1000BASE-T (o sea el Gigabit por cobre de toda la vida). Este producto se consigue por aprox. USD 250.
No convencido por ninguna de las dos, y sabiendo que traer usado de eBay estando en Uruguay es una timba, me puse a ver de nuevo el catalogo de MikroTik hasta que encontré que el CRS326-24G-2S+RM tiene todo lo que preciso quiero, y seria el candidato a remplazar mi actual CRS125 ya que:
- Tiene la opción de usar tanto SwOS como RouterOS, por lo cual puede seguir haciendo de router acá en casa, tal cual lo viene haciendo el CRS125 [*1].
- Viene con 24 interfaces Gigabit por cobre, al igual que el CRS125.
- Viene con 2 jaulas SFP+, que es lo que precisamos para lo que pretendemos hacer.
- Puede alcanzar el wire-speed teórico en lo que a switching se refiere (L2), en otras palabras puedo saturar el enlace 10Gbps entre las dos maquinas.
- Esta listado a USD 199. Anda saber cuanto cuesta en Uruguay (si se consigue siquiera) pero considerando que la bosta Netgear cuesta USD 250, no esta para nada mal.
[*1]: El CRS-125 (o cualquier CRS de MikroTik) es un switch, no un router. No esta pensado como router, por mas que puedas usarlo como tal dado que viene todas las funcionalidades. Dependiendo de lo que hagas, el throughput te puede sobrar o todo se puede caer a pedazos.
Dicho todo esto, nuestra lista de compras quedaría mas o menos así:
- 2x HP 614203-B21, USD 138
- 2x 10Gtek SFP+ DAC 3m, USD 30
- 1x MikroTik CRS326-24G-2S+RM, USD 200
- 1x Overhead de hacer que todo esto se materialice en la República Oriental del Uruguay (estimado pesimista): USD 253
- Total: USD 621
Nota: si la haces bien podes traer todo bajo franquicia, incluyendo el CRS326 ya que según Honey, supo estar a USD 139 en algún momento en Amazon. Esto reduce considerablemente la cometa estatal a pagar.
Buscando una excusa
Bueno ya vimos que dependiendo de como la juegue, la joda me puede llegar a costar 600 dólares en el peor escenario o al rededor de 370 dólares si se me da. El tema ahora no es lo que cuesta, mas bien “si lo vale”.
La principal (y probablemente única) ventaja que obtenga al hacer esto es un acceso ridículamente rápido al almacenamiento en el server, cosa que uso al punto tal que no solamente documentos, fotos, música, videos, películas y series se guardan ahí pero también los vmdk de las maquinas virtuales y recientemente las descargas de Steam:
En otras palabras, cuando bajo las fotos de la cámara, se guardan en la red. Cuando estoy haciendo algún desastre en Premiere, todo el footage viene de la red. Cuando tengo que virtualizar algo, a no ser que requiera la performance de I/O, el vmdk/vdi/vhd/vhdx/whatever esta en la red. Y así con prácticamente todo lo que no resulte un problema, en ese caso lo guardo o en el disco o SSD local.
Esta obsesión de mandar todo al storage arranco hace no mucho cuando me di cuenta de dos cosas:
- Tengo un montón de espacio disponible en el storage del server.
- El storage cuenta con redundancia, los discos de mi maquina no.
- El storage se respalda automáticamente, los discos de mi maquina no (yo respaldo manualmente ciertas cosas que considero importantes).
- El acceso a mi unidad de red es mas rápido que a los discos duros locales a la maquina.
Ese ultimo ítem fue el que me llevo realmente a coparme con la idea de un storage por red mas rápido, al ver que tener el pool de ZFS con estados sólidos haciendo de cache, la red era mi cuello de botella. En aquel momento, pensaba que si tan solo pudiera hacer link-aggregation entre los equipos y el switch…
El tema es, el CRS125 es un aparato bastante particular, tiene 24 interfaces las cuales podes o asignar a uno de los switches por hardware o manejarlas como interfaces independientes. Si bien puedo hacer agregación de enlaces, solo puedo hacerlo para interfaces que están por fuera del switch y por lo tanto tendría que tener un bridge entre esa agregación y el resto el switch y de solo pensar en todo eso pasando por el CPU del CRS me da dolor de cabeza (aunque un día con tiempo de sobra voy a probarlo).
Multi-gigabit de pobre
Bueno, resulta que tiempo después me entere que, si bien no puedo hacer link-aggregation propiamente dicho (o sea a lo LACP), tenia una alternativa llamada “bonding” (o teaming). Resulta que el kernel de Linux tiene un driver de bonding que me permitía hacer lo que yo quería y por lo tanto me le agregue al server una placa con cuatro interfaces Gigabit Ethernet y nació el “James Bond”.
Mientras que en Windows es tan fácil como crear un “NIC Team”… si estas en Windows Server. Al parecer a Microsoft se le “escapo” esa funcionalidad una vez en Windows 10 pero se dieron cuenta y la sacaron, tal como explica Adam Rudell en los foros de TechNet:
While the powershell cmdlet didn’t outright fail on client, LBFO was in a broken and unsupported state, since the client SKU does not ship the mslbfoprovider.sys kernel driver. That kernel driver contains all the load balancing and failover logic, as well as the LACP state machine. Without that driver, you might get the appearance of a team, but it wouldn’t really do actual teaming logic. We never tested NIC Teaming in a configuration where this kernel driver was missing.
Adam Rudell, Microsoft employee (allegedly), TechNet Forums
A pesar de que había gente en internet reportando que funcionaba, realizando pruebas de transferencia, pero bueno, supongo que lo archivamos en el armario de “Things Microsoft does”. Que tipos simpáticos.
La alternativa para hacer esto en Windows 10 es usar una placa de red que lo soporte a nivel de driver, lamentablemente estoy usando una de esas Intel PRO/1000 PT Dual Port que se consiguen por chirolas en cualquier parte y que funcionan muy bien en Windows, Linux & BSD pero el driver de Intel no soporta bonding en estas placas (fair enough: son bastante viejas).
SMB multichannel
No recuerdo bien como, pero de casualidad encontré que existe en SMB (el protocolo de File Sharing de Windows) una funcionalidad llamada multichannel y básicamente esto le permite a un cliente SMB utilizar múltiples conexiones simultaneas cuando transfiere archivos, sin necesidad de agregaciones o bondings o teams.
Mientras que del otro lado, depende de si usas Windows o Samba (la implementación open-source de SMB que nada tiene que ver con la fiesta brazuca). Si usas Windows se supone que en versiones recientes viene habilitado por defecto y no hay que hacer nada. Si usas Samba (de vuelta, nada de Brasil), tenes que estar en la versión >= 4.4.0 (cualquier distro decente hoy en día cumple con esto) y agregar al menos lo siguiente a la configuración de smbd:
server multi channel support = yes
aio read size = 1
aio write size = 1Si queres una guía que explique esto de SMB multichannel con Samba, te recomiendo el post de Daniel Vogelbacher (Chaospixel).
Lo único que importa, es que funciona… la gran parte del tiempo:
Pero no es perfecto dado que:
- Hay veces que no levanta el multichannel y transfiere a 1Gbps, vaya uno a saber porque.
- Tenia en mente usar al menos 3 adaptadores Gigabit en la PC de escritorio, dado que en el server hay 4. Por razones que desconozco, al agregar un tercer adaptador, SMB multichannel hace lo suyo pero se ve que el overhead me juega una mala pasada porque no llega a saturar los tres enlaces, de hecho la velocidad de transferencia es peor que con 2.
- Es una funcionalidad experimental y hay casos donde podría llevar a la corrupción de datos… oops!
CAVEAT: While this should be working without problems mostly, there are still corner cases in the treatment of channel failures that may result in DATA CORRUPTION when these race conditions hit. It is hence
NOT RECOMMENDED TO USE MULTI-CHANNEL IN PRODUCTION
at this stage. This situation can be expected to improve during the life-time of the 4.4 release. Feed-back from test-setups is highly welcome.
Samba 4.4.0 Release Notes
Quiero mas
Lamentablemente, ya mordí la manzana. Pasar de 1Gbps a 2Gbps puede ser que no parezca mucho, pero en mi caso, esperar media hora a que se copie algo en lugar de una hora entera se siente. Mas importante aun, 2Gbps ya es suficientemente rápido para sacar los discos duros del PC y quedarme solo con el SSD y el storage por red. Por ahora la única contra que le veo es si por algún motivo el storage queda inaccesible durante un tiempo extendido, por ejemplo, si falla el mismo.
Ah, y esta ese detalle menor que SMB multichannel en Samba es experimental y puede ocasionar perdida de datos.
Estuve considerando también otras opciones “multi-gigabit” como 2.5Gbps y 5Gbps pero lamentablemente no se consigue mucho de eso y tendría que cambiar el switch de todas formas, así que 10Gbps no parece algo muy loco, sobre todo si puedo conseguir traer las partes dentro del régimen de franquicias porque seguro que hoy en día no me justifico pagar USD 600 por 10GbE entre el server y el desktop.
De todas formas, todo esto pende de una cosa sola, la cual debería ser la mas obvia: a que velocidad puedo sacar y meter datos del storage?
Solo hay una manera de averiguar y es comprar todo y ver que onda correr unos benchmarks a la carrera, hacer una gráfica y ver que pasa:
Bueno, que manera de pinchar el globo. Las observaciones son:
- Usar una unidad de red contra el pool ZFS (o contra un SSD fuera del pool), teniendo 2Gbps es mas rápido que los discos duros SATA que están conectados al PC.
- El pool ZFS del server puede ir mas rapido que mi conexion de 2Gbps, pero no mas rapido que 3Gbps.
Ahora bien, el benchmark del pool ZFS se corrio de manera tal que nos evitaramos el cache en RAM, dado que me interesaba la performance del pool en si.
Sin embargo, en un uso real, el cache de I/O esta siempre ahi dando la nota, por lo cual corresponde volver a correr el benchmark como un gentleman, teniendo el cache en cuenta. Veamos que pasa:
LPM, ahora tengo que hacer todo este post de nuevo, pero para 25 Gigabit Ethernet [*2]. Pero mientras tanto… SAMBA!!
[*2]: Si y no. El cache del filesystem en memoria puede ayudarme mas que nada al correr programas, donde aplica algo similar al “principio de localidad“. Para la ida y vuelta de archivos grandes no le veo que pueda aportar mucho.