Prepare for the SSD price wars!

Long ago I guessed that when SSD prices per Gb start to converge to HDD ones, people will stop buying old and slow HDD and start using SSD for almost anything. They’re smaller, no moving parts, more durable than HDD. They had flaws, and some of them still are valid, but we should not forget that HDD have a lot of flaws, just we got used to them and seem fine to us.

Today, as this price gap is getting smaller, and also 250Gb/512Gb SSD devices are available at cheap prices (for example 512Gb drive can be bought today starting at 83€), things are start to change in manufacturers. We’re starting to see a few news that are clear indicators that this is happening.

Imagine the situation: Manufacturers of laptops used to put HDDs on every unit, but now, they could choose between 1TB 2.5″ HDD for 47€ or 512Gb SSD for 83€ (they will get cheaper ones as those are retail prices). SSD are very appreciated by users, they make the laptop faster, they use less energy so the manufacturer can advertise better battery durability. And less prone to problems from shocks, as users carry their laptop, HDD could have some problems. What would you do in this case? Probably put an SSD and increase the price tag by 40€ which is almost unnoticeable for laptops that may cost 600€ or higher.

So you can guess which is the current situation: The HDD demand is dropping, and is expecting to drop even more. Because of this new SSD demand we got a price increase in the last 2 years because manufacturers couldn’t catch up with the production rate. Maybe they have been caught by surprise (or maybe they did this in purpose to get funds for research, who knows). But the thing is this trend stopped months ago and prices started to drop again. They increased the rate of production probably.

And now, Western Digital announced that they’re closing a hard drive factory, because they’re shifting to produce more SSD and less HDD units.

This is not the only news we received recently. Toshiba announces a new technology for SSD that will increase the capacity 5 times and will be in mass production next year. Western digital seems is researching on the same thing.

What will happen? No body knows but my guess here is, first thing the sweet spot for best value SSD will move from the 512Gb devices to 2-3Tb. The price for those will end falling about 3 times, so maybe they get into 180€ for 3Tb. As you get less capacity the prices will drop less, and for higher capacities they will get more or less same price per Gb as the 3Tb ones.

The real question is when. It is clear that they will try to release early the highest capacity possible (12Tb?), using the current price per Gb, maybe a bit cheaper. Those are targeted to data centers where space really matters, and having 12Tb devices of 2.5″ is really interesting for them. Even if datacenters know (of course they know) that those devices will become cheaper in 3 years, the investment is still worth it, as they swap lots of drives after 5 years of use.

So, when prices will be that low? I’ll risk it by putting a date: October, 2021. Manufacturers are not stupid. Even if they start a price war on SSD, it will be mostly faked. There is a lot of money in this goldmine and they want all of it. They will just stick to the old trend if possible. Maybe it will break the trend a bit because of the amount of sales, but don’t expect much.

By 2022, expect almost everything shipping SSD and nothing with HDD.

What is going to get super-interesting on the next year is the M.2 format. Even thinner and faster than SATA ones, laptops are again a great fit for this, but servers and desktops too. And also I guess datacenters will start soon thinking about M.2 or U.2 for hotswap, but as the M.2 doesn’t support it, probably it will be eiher using U.2 (which seems they are deprecating it) or making it somehow hot swappable.

So my piece of advice is, if you are buying a computer, make sure it has M.2 slots on it. They are going to be very useful in the next 4 years.

Particionando servidores Linux

Instalas un servidor nuevo Linux y la pregunta eterna en el instalador: particiones. ¿Cómo las hago? ¿Qué es mejor? Y muchas veces terminamos con un sistema de particiones que es incorrecto o no funciona.

En este post voy a explicaros un poco cómo debería particionarse el servidor. El RAID, para qué es bueno y cómo usarlo. Los backups o redundancia de datos, cómo plantearla. Los distintos tipos de formato de partición que existen.

Primero que nada, si no tenemos idea de cómo hacer las particiones, ante la duda, nunca uséis RAID, y particionad el disco principal con las opciones por defecto. Si tenéis un disco secundario le creáis una sola partición estándar y guardáis allí los backups. Sencillo, funciona, y no os podéis equivocar.

Si la controladora de la placa base os obliga a hacer RAID, mirad las opciones de la BIOS para desactivar la controladora entera. Normalmente hay otra disponible que no hace RAID. Si no es posible o no lo encontráis, haced un RAID 0 (cero) de cada disco por separado. Esto es, si tienes tres discos, haces tres RAID 0 de un disco.

Estas son las instrucciones para los que quieran terminar rápido o tengan dudas. Este tipo de particionado está lejos de ser idóneo pero es bastante mejor que particionar mal.

Ahora entraré a analizar con detalle el particionado correcto, pero antes vamos a ver un par de conceptos base que tenéis que tener claros.

RAID, qué es y qué no es

RAID son las siglas de “Redundant Array of Inexpensive Disks” (Array redundante de discos económicos) y su objetivo es reducir las pérdidas de datos debido a problemas de escritura en el disco. Todos los demás tipos de protección contra pérdida de datos requieren de otras medidas adicionales.

La otra función de RAID es hacer que las lecturas y escrituras tengan tiempos más estables, más rápidas y en definitiva, que un disco fallando no deje el servidor colgado.

Irónicamente RAID dice “Inexpensive Disks” pero RAID está pensado para discos caros y no para discos baratos. Os explico: Los discos baratos, que son para usuario normalmente, van a revisar las escrituras: escribir + leer + reescribir hasta que la escritura sea satisfactoria. Hasta el punto de reubicar sectores silenciosamente si están dañados. Este tipo de discos, al camuflar todos los fallos y bloquearse hasta repararlos, son prácticamente inservibles en RAID a no ser que se consiga cambiar el firmware para que trabajen de forma distinta.

Si piensas en usar RAID, deberías usar discos duros de servidor. Muchas veces son los mismos discos que los de usuario pero con otro firmware, y más caros.

Pero lo más importante que debería quedarse grabado en nuestra cabeza es: RAID no es un backup. No puedo enfatizarlo más pero puedo ponerlo en letra más grande si eso.

RAID NO ES UN BACKUP

En ningún sentido. Ni RAID 1 ni RAID 10 ni ninguno te va a evitar hacer backups. TIENES QUE HACER BACKUPS tanto con RAID como sin él. ¿Queda claro?

Los backups sirven para una serie de cosas (desastres, borrados inesperados, fallos totales de hardware, recuperar versiones antiguas) y el RAID sirve para mantener un servidor funcionando el mayor tiempo posible sin paradas.

Si aún así vais a usar RAID, debéis saber que existen tres tipos: software, hardware e híbridos.

  • Software RAID: Es el que instalas con Linux por ejemplo. Normalmente es mdraid. Se ejecuta en la CPU por lo que ralentece el sistema, pero muy poco (0.5%). Es más flexible y permite administración remota por ssh.
  • Hardware RAID: Es el que tiene una tarjeta dedicada (y cara-carísima) para ello. Ponedla con batería y cambiadla cada dos años, por el amor de dios. Y no, la placa base no trae Hardware RAID por mucho que insistan. Ideal si alguien experto va a revisar el servidor cada 3 meses. Tened un plan de rotación de discos!
  • FakeRaid o Híbrido: Es el de las placas base, se hace una parte en la placa y la otra se hace por software. Da un montón de problemas. Lo peor de ambos mundos en un sólo sistema.

Y no uséis RAID 5. Es otro coladero bastante grande. RAID 1 es lo mejor a pequeña escala. RAID 6, 10 o 0+1 para gran escala y RAID 0 para datos volátiles rápidos.

Plantead también HotSwap, que sino no sé para qué queréis RAID.

A pequeña escala, una copia nocturna con rsync de disco a disco cuando no hay nada en uso puede ser mejor que RAID en caso de desastre.

Si os interesa saber más de porqué no usar RAID o cómo usarlo correctamente y sus problemas típicos, comentádmelo y os hago un artículo.

Formatos de partición

En Windows básicamente hay FAT y NTFS. Los dos son bastante horribles. En Linux el problema es que hay demasiados donde elegir. Los enumero:

  • Ext2, Ext3, Ext4: Son los sistemas de ficheros estándar en Linux. Están diseñados para funcionar lo mejor posible independientemente del uso que le demos. Lo recomiendo, y usad la última versión que dispongáis.
  • Xfs: Un sistema de ficheros pensado en ser veloz para escribir ficheros pequeños. Funciona muy bien con bases de datos. Ofrece menor seguridad de datos que Ext3 y Ext4, pero si la base de datos ya tiene su propio sistema, como PostgreSQL, la verdad es que vale la pena. También da menos problemas que Ext4 cuando inicia y encuntra errores ya que pide menos intervención del usuario. Ext4 se puede configurar para que funcione similar a Xfs.
  • ReiserFS, Reiser4: Fueron pensados para ser tremendamente veloces. Pero consumen CPU más de la cuenta y presentan fuertes pérdidas de datos cuando se apagan los equipos incorrectamente. No los recomiendo.
  • Btrfs, ZFS: Son sistemas de ficheros tipo “log”. Añaden casi siempre de izquierda a derecha sin sobreescribir. Tienen un montón de ventajas a la hora de hacer backups y desduplicar datos del disco. También soportan compresión y comprobación de errores a nivel de bloque. Son bastante buenos, pero en discos de aguja tradicionales se suelen ralentizar bastante porque fragmentan los ficheros por defecto. Con SSD van relativamente bien.

Recomiendo que uséis Ext4 a no ser que sepáis lo que estáis haciendo. Probad los otros en servidores que no sean de producción y podáis permitiros reinstalarlos si no quedáis contentos. La experiencia aquí es lo que cuenta, y con Ext4 no te puedes equivocar.

Particionando discos

Y ya llegamos por fin a lo que iba. Cómo particionar un disco y qué discos poner.

Lo más sencillo es que el servidor tenga dos discos. Uno para el trabajo diario, más rápido y pequeño, y otro grande y seguro para los backups.

Si es posible, el primer disco que sea un SSD de servidor. No valen los Samsung PRO. Aquí no se trata de velocidad ya, porque cualquier SSD es diez veces más rápido que un HDD. Se trata de durabilidad, y no quieres que tu servidor falle por completo a los 4 años por desgaste del disco, ¿verdad?

Los discos SSD de servidor son generalmente Samsung o Intel, y tienen un precio que es el triple o más que los demás discos, ofreciendo la misma velocidad. La diferencia es que están garantizados para escribir en ellos 15 PetaBytes o más. Por ejemplo:

https://www.samsung.com/semiconductor/minisite/ssd/product/enterprise/overview/

El Samsung PM863a de 1Tb se vende a 475 dólares en Amazon. Puede parecer muy caro pero os aseguro que es un precio excelente. Son más fiables que un HDD y eso es decir mucho.

Como disco secundario hay que elegir uno grande para hacer backups y que sea fiable. HGST es la mejor marca para discos duros fiables. No pongáis Seagate. Con Western Digital (WD), depende del modelo.

Dependiendo de los requisitos, puede ser un SSD de 480Gb + HDD de 2Tb o un SSD de 1Tb y HDD de 6Tb. Opciones hay muchas, yo os doy dos ejemplos.

Al particionar el primer disco, primero hay que crear una partición para /boot/. Ésta partición será Ext3. El motivo de esta partición es que cuando arranca el kernel, éste intentará montar /boot/ si existe o en su defecto la partición raíz /. Y el primer montaje es muy limitado porque el kernel aún no ha podido cargar los módulos completamente (pues se hospedan en /boot/). Si nuestra partición raíz tiene opciones de montaje especiales, o es de un tipo especial (y no Ext3), es posible que el Kernel falle al intentar montarla.

Así que, para evitar sustos, cread una partición estándar Ext3 con las opciones por defecto para /boot/. Normalmente con 1Gb es más que de sobra. Y con 500Mb también.

Si vais a querer optimizar para la base de datos, cread una partición en /var/lib/. Al menos en Debian las bases de datos van allí. XFS puede ser buena opción. O Ext4 con opciones específicas como noatime y data=writeback. También en el caso de SSD se puede usar Btrfs para sacar provecho del Copy On Write o backups en caliente. El tamaño de la partición debería ser bastante más grande que la base de datos que queréis tener. Dadle espacio porque luego es costoso cambiarlo. Normalmente unos 200Gb.

En el segundo disco se puede ubicar una partición de 50Gb para /var/log, el objetivo de esto es evitar que los logs llenen la partición primaria por un error y esto tiende a crear pérdida de datos.

También se puede crear una partición /home en el segundo disco de unos 500Gb, para evitar que lo que guardamos allí afecte al sistema. Además el acceso a /home lo realizamos al conectarnos al servidor, así que no debería haber problema de rendimiento.

Finalmente, en el SSD, creamos una partición Swap de unos 16Gb y el resto lo llenamos con una partición Ext4 para la raíz.

En el disco secundario una partición del resto del espacio para /var/backups. Cuando hagáis vuestros script de backup, que vuelquen los datos allí dentro, en una subcarpeta.

El objetivo de todo esto es que si uno de los discos falla por completo, con los datos de uno puedas regenerar (más o menos) los datos del otro, con pérdidas mínimas o aceptables.

Los backups, por supuesto, una vez grabados deberían enviarse a otro sitio. Si podéis copiar los backups también a un disco externo, a otro servidor o disco de red usando FTP o Rsync, mejor. FTP no es demasiado fiable, así que id con cuidado. Hay que llevarse un backup a casa y hacer rotación de discos de backup para estar seguro. También podéis subir los datos a la nube si el ancho de banda os lo permite.

La gracia de tener un disco de backup instalado en el mismo servidor es que tienes un acceso muy rápido a los backups, por lo que si se ha borrado algo accidentalmente lo podemos restaurar enseguida. Además, por lo general los fallos de un disco no afectan al otro a no ser que sean misma marca, modelo y remesa (aunque a veces pasa con subidas de tensión. Poned un SAI bueno que os proteja el servidor). Que el 90% de los fallos no afecten a los dos discos duros no es excusa para no grabarlos también fuera. Es comodidad para restaurar, pero no es suficiente por sí mismo.

Espero que os haya ayudado a decidir cómo particionar los servidores!