<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Infraestructura on Alefnode</title><link>https://blog.alefnode.com/tags/infraestructura/</link><description>Recent content in Infraestructura on Alefnode</description><generator>Hugo</generator><language>es-ES</language><lastBuildDate>Wed, 04 Jun 2025 19:20:00 +0100</lastBuildDate><atom:link href="https://blog.alefnode.com/tags/infraestructura/index.xml" rel="self" type="application/rss+xml"/><item><title>El Secreto de mi HOMELAB</title><link>https://blog.alefnode.com/blog/explicando-mi-homelab/</link><pubDate>Wed, 04 Jun 2025 19:20:00 +0100</pubDate><guid>https://blog.alefnode.com/blog/explicando-mi-homelab/</guid><description>&lt;p&gt;La gente cree que construir un homelab se trata de gastar dinero en hardware caro. Pero eso es solo la mitad de la historia. El verdadero poder de un homelab no reside en sus máquinas, sino en la forma en que las conectas. Y a veces, esa conexión va más allá de las paredes de tu casa.&lt;/p&gt;
&lt;p&gt;En mi caso, la &amp;ldquo;forma&amp;rdquo; en que conecto mi homelab ha evolucionado hasta el punto de que se extiende a través de múltiples datacenters. Sí, has leído bien. No me limito a un solo servidor en mi habitación; tengo recursos distribuidos en varios centros de datos, todos funcionando como una sola red interna. La razón detrás de esto va más allá de la redundancia o la experimentación; es la búsqueda de la máxima flexibilidad y eficiencia.&lt;/p&gt;</description></item><item><title>Desplegando un cluster de K3S con Elemental</title><link>https://blog.alefnode.com/blog/desplegando-un-cluster-de-k3s-con-elemental/</link><pubDate>Wed, 09 Oct 2024 22:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/desplegando-un-cluster-de-k3s-con-elemental/</guid><description>&lt;p&gt;En este post explicaremos cómo usar el toolkit de Elemental, un producto de código abierto para desplegar un clúster productivo de K3S. Primero, revisaremos las definiciones básicas del software que vamos a utilizar.&lt;/p&gt;
&lt;p&gt;Por un lado, tenemos K3S, un software de orquestación de contenedores muy similar a Kubernetes (K8S) y OpenShift, pero con la particularidad de ser mucho más ligero. Para lograr esta eficiencia, los desarrolladores han eliminado componentes opcionales de un clúster Kubernetes, dejándolo con lo esencial para funcionar. Esto hace que los requisitos mínimos para un despliegue de K3S sean entre 2 y 3 veces menores que los de K8S, y hasta 7 u 8 veces menores que los de OpenShift.&lt;/p&gt;</description></item><item><title>Desplegando un cluster productivo de OKD</title><link>https://blog.alefnode.com/blog/desplegando-un-cluster-productivo-de-okd/</link><pubDate>Mon, 11 Dec 2023 19:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/desplegando-un-cluster-productivo-de-okd/</guid><description>&lt;p&gt;En este artículo vamos a explicar el proceso para el despliegue de un cluster productivo de OKD sobre un virtualizador de KVM en el cual no disponemos de cloud-init por lo que el proceso de despliegue se hace siguiendo la documentación como si lo desplegasemos sobre un entorno de &lt;em&gt;baremetal&lt;/em&gt;, &lt;strong&gt;de hecho este mismo artículo serviría si queremos hacer el despliegue sobre un entorno baremetal&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;Denominamos este cluster como productivo, ya que vamos a hacer un despliegue de un total de 5 nodos de Fedora CoreOS, de los cuales 3 servidores van a corresponderse con nodos &lt;em&gt;master&lt;/em&gt; y 2 de ellos serán los denominados nodos &lt;em&gt;worker&lt;/em&gt;, para entender mejor este despliegue, os dejo una imagen con un esquema de los componentes con sus IPs de tal forma que si a lo largo del artículo no se entiende alguno de los elementos se pueda revisar la imagen para entenderlo mejor.&lt;/p&gt;</description></item><item><title>Desplegando un cluster de Kubernetes con Kubespray</title><link>https://blog.alefnode.com/blog/desplegando-un-cluster-de-kubernetes-con-kubespray/</link><pubDate>Sat, 09 May 2020 21:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/desplegando-un-cluster-de-kubernetes-con-kubespray/</guid><description>&lt;p&gt;La mejor forma de aprender todos los componentes de una herramienta es instalar a mano toda la herramienta, sin embargo, esto puede convertirse en una tarea muy tediosa si hablamos de Kubernetes, cabe mencionar que antes de llegar a este punto probé diferentes formas de instalación.&lt;/p&gt;
&lt;p&gt;La primera instalación de un cluster de Kubernetes que probé hace ya algunos años fue una instalación a mano y aprovechando los pasos fui preparando mi propio playbook de ansible que permitía luego una instalación automatizada. Me permitía así la posibilidad de escalar el cluster sin problemas, además dado que ya tenía todos los pasos lo adapté para que funcionara tanto en distribuciones basadas en Debian como en Centos.&lt;/p&gt;</description></item><item><title>Desplegando un cluster de Kubernetes con Skuba</title><link>https://blog.alefnode.com/blog/desplegando-un-cluster-de-kubernetes-con-skuba/</link><pubDate>Tue, 12 Nov 2019 18:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/desplegando-un-cluster-de-kubernetes-con-skuba/</guid><description>&lt;p&gt;&lt;a href="https://github.com/SUSE/skuba"&gt;Skuba&lt;/a&gt; es una herramienta desarrollada por SUSE y cuyo código se encuentra publicado en su repositorio de Github que nos simplifica el despliegue y la actualización de un cluster de Kubernetes. Esta herramienta se basa en kubeadm para el despliegue y se encuentra programada en Go.&lt;/p&gt;
&lt;p&gt;En este post vamos a indicaros como podéis deplegar un cluster de Kubernetes con dos masters y dos workers sobre la distribución openSUSE, se basa en el sistema SUSE CaaSP v4 pero al hacerlo sobre otra distribución no tendremos soporte por lo que será interesante para hacer pruebas y PoC para posteriomente realizar una instalación con soporte.&lt;/p&gt;</description></item><item><title>Habilitando CEPH en Kolla</title><link>https://blog.alefnode.com/blog/habilitando-ceph-en-kolla/</link><pubDate>Mon, 15 Oct 2018 19:00:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/habilitando-ceph-en-kolla/</guid><description>&lt;p&gt;En este artículo vamos a ver como podemos habilitar CEPH en un cluster de 3 servidores cuyas características revelantes para este post son.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Servidor: Blade BL460C Gen8&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Numero de discos duros: 2&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Discos duros: HP SAS 15K 300G&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;En primer lugar cabe destacar que solo disponemos de 2 caddies para discos, lo que significa que si queremos destinar un disco completo para CEPH (recomendable) vamos a tener que prescindir de utilizar la tarjeta raid por hardware que tenemos instalada, en este sentido vamos a perder performance, sin embargo, como estamos en una arquitectura de 3 nodos replicados no supone ningún tipo de problema en cuanto a estabilidad.&lt;/p&gt;</description></item><item><title>Aislando proyectos en Openstack</title><link>https://blog.alefnode.com/blog/aislando-proyectos-en-openstack/</link><pubDate>Wed, 03 Oct 2018 13:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/aislando-proyectos-en-openstack/</guid><description>&lt;p&gt;En Openstack tenemos diferentes formas de crear una arquitectura en la cual tengamos a nuestros clientes aislados (en cuanto a red se refiere), por un lado podemos preparar nuestros equipos de red para utilizar VLANs o VXLANs y taguear una diferente a cada uno de nuestros clientes de formas que cada red esté completamente aislada al mismo tiempo que tagueamos nuestra red pública para que puedan disponer de la asignación de IPs públicas.&lt;/p&gt;</description></item><item><title>Esquema CDN de Alefnode</title><link>https://blog.alefnode.com/blog/esquema-cdn-de-alefnode/</link><pubDate>Fri, 28 Sep 2018 11:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/esquema-cdn-de-alefnode/</guid><description>&lt;p&gt;Hoy os presentamos como se encuentra funcionando actualmente el CDN que está misma web está utilizando, Alefnode CDN.
Las configuraciones son complejas y la arquitectura no es lo más común en un CDN, sin embargo, mediante diversas pruebas hemos conseguido llegar a límites que hasta ahora no eran alcanzables con una estructura similar.
Como podéis observar estamos trabajando con un servidor de DNS que realiza distinciones por país y envía la petición a nodos diferentes en función de la geolocalización del usuario, lo que nos permite no solo tener una menor latencia sino también un menor tiempo de carga. Una vez la petición está en el nodo del CDN lo que hacemos el revisar las peticiones ya cacheadas en el cluster de servidores noSQL para servirlas directamente desde su RAM, lugar en el que se almacenan todos los ficheros cacheados. En caso de no encontrarse en el cluster, se realiza la petición al servidor, en este caso un frontend con Angular4 que conecta con un backend de Worpress mediante peticiones API REST.
El primer test que realizamos es conseguir mantener 500 clientes concurrentes por segundo durante un minuto, lo que significa que estamos soportando un total de 1000 peticiones por segundo. Obtenemos un tiempo de carga medio de 306ms en un total aproximado de 70k peticiones, en las cuales la respuesta tiene que contener la primera imagen de la entrada del blog.&lt;/p&gt;</description></item><item><title>Disaster recovery en CEPH</title><link>https://blog.alefnode.com/blog/disaster-recovery-en-ceph/</link><pubDate>Tue, 25 Sep 2018 10:30:00 +0600</pubDate><guid>https://blog.alefnode.com/blog/disaster-recovery-en-ceph/</guid><description>&lt;p&gt;En la actualidad en las arquitecturas cloud se está utilizando el SDS que significa Software Definied Storage, la idea principal de estos sistemas es tratar el almacenamiento como si fuese software independientemente del hardware físico que tengamos. Este tipo de sistemas facilita mucho a las empresas el cambio de hardware, por uno de mejores prestaciones, reduciendo el tiempo de migraciones a cero. Algunos ejemplos de SDS son; CEPH, Swift, pNFS, SDDC by VMWare,&amp;hellip;&lt;/p&gt;</description></item><item><title>Orquestando instancias en Openstack</title><link>https://blog.alefnode.com/blog/orquestando-instancias-en-openstack/</link><pubDate>Sat, 08 Sep 2018 10:30:41 +0600</pubDate><guid>https://blog.alefnode.com/blog/orquestando-instancias-en-openstack/</guid><description>&lt;p&gt;Desde hace algún tiempo me dedico a la automatización de cierto proyectos que tienen como fundamento la capacidad de funcionar de forma autónoma, es decir, pueden adaptarse a las necesidades que se soliciten en cada momento. Para poder realizar este tipo de tareas debemos conocer como orquestar toda nuestra plataforma.&lt;/p&gt;
&lt;p&gt;En primer lugar debemos saber exactamente de que hablamos cuando nos referimos a orquestar, para ello se define el verbo orquestar como organizar, dirigir o coordinar un plan. En el ámbito tecnológico se utiliza la orquestación para la planificación de despliegues ya bien sean de forma automática o manual.&lt;/p&gt;</description></item><item><title>HaProxy un servidor por cada dominio</title><link>https://blog.alefnode.com/blog/haproxy-un-servidor-por-cada-dominio/</link><pubDate>Tue, 28 Aug 2018 17:04:41 +0600</pubDate><guid>https://blog.alefnode.com/blog/haproxy-un-servidor-por-cada-dominio/</guid><description>&lt;p&gt;Haproxy es un software opensource que nos permite tener nuestro propio balanceador de carga en casa. Lo bueno de esta aplicación es que nos permite disponer de alta disponibilidad en formato Activo-Activo de forma sencilla y al mismo tiempo disponer de un potente software diseñado exclusivamente a esta tarea.&lt;/p&gt;
&lt;p&gt;Una de las opciones que se puede utilizar es mantener nuestros certificados de diferentes webs todos centralizados con una mayor facilidad a la hora de gestionarlos, asi como, balancear las peticiones de cada web a un servidor diferente, evitando que la carga de una web afecte a otra web.&lt;/p&gt;</description></item></channel></rss>