7 puntos por GN⁺ 2024-12-23 | 3 comentarios | Compartir por WhatsApp
  • Ha aumentado la discusión sobre la repatriación desde la nube a hardware propio
  • Fastmail lleva más de 20 años optimizando su operación con servidores bare metal propios
  • Usar hardware propio permite optimizar costos frente a la nube:
    • Comprender con precisión los patrones de uso para planificar a largo plazo la compra de hardware
    • 25 años de experiencia acumulada en instalación y operación de hardware y networking
    • Amortización del costo del hardware durante 5 a 10 años de uso

Evolución del hardware

  • Los servidores IMAP iniciales usaban arreglos RAID con discos SAS de 15k RPM y SATA de 7.2k RPM
  • Los datos de correo se guardaban primero en discos SAS de alta velocidad y luego se movían a discos SATA en momentos de baja carga del servidor
  • Este sistema se soportaba mediante Cyrus IMAP y una herramienta de particiones separada

Migración a NVMe SSD

  • Hace unos años se realizó una actualización importante a una plataforma de 2U basada en AMD con NVMe SSD
    • El rendimiento y la densidad de almacenamiento mejoraron significativamente
  • Debido a la falta de controladoras RAID, se adoptó el sistema de archivos ZFS
  • ZFS ofrece un rendimiento de I/O excelente gracias al modelo copy-on-write

Compresión y ajuste fino de ZFS

  • Con compresión Zstandard se redujo cerca de un 40 % del espacio de los datos de correo
  • Ajustar el tamaño de registro de ZFS mejoró aún más la eficiencia de la compresión:
    • Un tamaño de registro de 128k reduce alrededor de un 40 %
    • Al ajustarlo a 512k, la reducción llega al 42 %

Cifrado e integración con ZFS

  • Reemplazo del cifrado LUKS tradicional por el cifrado nativo de ZFS para reducir la complejidad del sistema
  • En 3 años se completó la adopción de ZFS en todos los servidores de correo, bases de datos, logs y servidores de respaldo

Vida útil y confiabilidad de SSD

  • Verificación de vida útil y confiabilidad de SSD:
    • Los SSD de centro de datos registraron una tasa de fallos muy baja durante 3 años
    • Más de 10 veces más confiables que HDD

Comparación de costos de almacenamiento

Almacenamiento en la nube

  • Amazon S3: USD 252,000 al año
  • Backblaze B2: USD 72,000 al año
  • Ventajas: almacenamiento ilimitado, selección de múltiples proveedores
  • Desventajas: complejidad de implementación, posibilidad de aumento continuo de costos

Actualización de HDD

  • Costo de actualización HDD 24TB: alrededor de USD 6,000 por servidor
  • Ventajas: reutilización del hardware existente, bajo costo
  • Desventajas: mayor tiempo de recuperación de datos, insuficiente rendimiento de I/O

Servidor SSD NVMe

  • Servidor SSD 2U: USD 190,000 (1220 TB de capacidad)
  • Ventajas: alto rendimiento de I/O, confiabilidad, ahorro de espacio y energía
  • Desventajas: costo inicial alto

Elección final y resultados

  • Migración a servidores ZFS basados en NVMe SSD:
    • Alto rendimiento y confiabilidad
    • Compatible con el sistema existente sin necesidad de nuevo desarrollo
    • Velocidad de transferencia de datos: más de 5GB/s

Conclusión

  • Operar con hardware propio no es para todos, pero puede mejorar el ahorro de costos y el control a largo plazo
  • Fastmail logra estabilidad y eficiencia de costos con hardware propio

3 comentarios

 
colossus 2024-12-24

Me pregunto si también se puede asegurar la disponibilidad a nivel de unidad de AZ.

 
spp00 2024-12-23

Honestamente, una empresa que funciona bien sin operar en la nube, que no la usa, suele ser una de dos cosas: o de verdad tiene un nivel de personal excelente y por eso va bien, o es un caso donde el nivel del personal no es bueno y el sistema tiene baja disponibilidad y seguridad débil, pero se percibe que funciona. En Corea, el segundo caso es abrumadoramente mayoritario. Si exceptuamos los puestos profesionales altamente especializados, en Corea se tienden a subestimar a las personas, así que en un caso como ese creo que es más adecuado dejarlo en manos de un CSP extranjero que sí usa buen talento. O invertir en gente de verdad…

Honestamente, si el número de usuarios conectados es constante, operar sin nube puede salir más barato, pero para que funcione bien con alta disponibilidad y seguridad se necesita talento capaz de hacer funcionar servidores físicos. Si no hay esa gente, lo correcto es usar la nube; una startup que no tiene la capacidad de contratar ese talento no usa la nube a la ligera.

Incluso 37Signals, que afirma no usar nube, fija un sueldo mínimo y valora el talento; ese mínimo es de 70 mil dólares, y con la suba del tipo de cambio en dólares, en wones supera los 100 millones. Entre los trabajadores de TI en Corea es común ganar menos que ese piso salarial de 37Signals. Allí la inversión en nómina es enorme porque se prioriza el talento, y aun así, aun contando con personas capaces de manejar on-premise, como tanto dinero iba a la nube, regresaron al bare metal. Además, hicieron cosas como Kamal. Pero, ¿las empresas coreanas tienen capacidad para hacer algo como Kamal? Si no se quiere invertir en personas, creo que lo correcto es usar un CSP como AWS. Lo de que on-premise sea seguro no es cierto, como quedó demostrado en el caso de hackeo de Kadokawa.

 
GN⁺ 2024-12-23
Opiniones de Hacker News
  • FastMail usaba su propio hardware porque, cuando la empresa se fundó en 1999, no había muchas opciones. Usaban un único servidor de Rackspace, y en ese momento costaba 70 USD al mes. En la práctica no había alternativas de VPS ni SaaS.

    • Después de que Rob se unió, al crecer los servidores consideraron la colocation. IBM y NYI se encargaban bien del soporte remoto y de los problemas de hardware.
    • Cuando Bron se incorporó, automatizaron todo. Operaban de forma económica y confiable con Linux, herramientas de código abierto y Perl.
    • Aunque servicios en la nube como AWS se pusieron de moda, siguieron prefiriendo servidores bare metal por el precio y la complejidad.
    • Existe preocupación por la creciente dependencia del SaaS, aunque planean hacer formación.
  • El cambio a la nube es interesante. La mayoría de las personas no quiere gestionar el hardware, pero en costos, el sistema propio sale mejor.

    • El argumento a favor de la nube parece estar dirigido a convencer a quienes tienen poca comprensión técnica.
    • La razón para apoyar la nube son el costo, la privacidad, la seguridad y evitar la centralización de Internet.
    • Aprecio el enfoque de FastMail porque no se mueve por emociones. Parece que la euforia por la nube está disminuyendo.
  • La nube se relaciona con el “left shift” de DevOps. Reducir costos no es su propósito principal.

    • En hardware, aprovisionar sistemas toma mucho tiempo, pero en la nube se puede hacer con un script simple.
    • Si tienes una carga de trabajo predecible y una cultura de ingeniería sólida, puede que la nube no sea necesaria.
  • No confío en FastMail. Después de adquirir Pobox, el servicio falló en el reenvío de correo electrónico. También rechazaron un reembolso.

  • Mencionan BareMetalSavings.com, que permite estimar el costo de salir de la nube.

    • Hay que tener cuidado porque el cifrado de ZFS puede ser inestable.
  • Me interesa el enfoque de FastMail. Se citan dos puntos curiosos sobre SSD.

    • Las unidades SSD son mucho más confiables que las HDD.
  • Me agradan la transparencia y las decisiones lógicas de FastMail. Vale la pena pagar por un servicio de correo electrónico.

  • Hay muchas opiniones de que el autoservicio funciona mejor que la nube. Sin embargo, hay poco debate sobre cómo operar aplicaciones de negocio de forma eficaz.

    • Existen varias capacidades necesarias para gestionar infraestructura. Usar SaaS puede anular el propósito de una infraestructura on-premise.
  • Una de las ventajas de usar la nube es la confiabilidad en pequeña escala.

    • Usando AWS, en pequeñas escalas la nube es la mejor opción.
  • FastMail era uno de los mejores proveedores de correo electrónico. La interfaz era intuitiva y ágil.

    • Me pasé a Protonmail, pero estoy considerando volver, porque la experiencia de uso con FastMail era buena.