- After-Shows
- Alternative
- Animals
- Animation
- Arts
- Astronomy
- Automotive
- Aviation
- Baseball
- Basketball
- Beauty
- Books
- Buddhism
- Business
- Careers
- Chemistry
- Christianity
- Climate
- Comedy
- Commentary
- Courses
- Crafts
- Cricket
- Cryptocurrency
- Culture
- Daily
- Design
- Documentary
- Drama
- Earth
- Education
- Entertainment
- Entrepreneurship
- Family
- Fantasy
- Fashion
- Fiction
- Film
- Fitness
- Food
- Football
- Games
- Garden
- Golf
- Government
- Health
- Hinduism
- History
- Hobbies
- Hockey
- Home
- How-To
- Improv
- Interviews
- Investing
- Islam
- Journals
- Judaism
- Kids
- Language
- Learning
- Leisure
- Life
- Management
- Manga
- Marketing
- Mathematics
- Medicine
- Mental
- Music
- Natural
- Nature
- News
- Non-Profit
- Nutrition
- Parenting
- Performing
- Personal
- Pets
- Philosophy
- Physics
- Places
- Politics
- Relationships
- Religion
- Reviews
- Role-Playing
- Rugby
- Running
- Science
- Self-Improvement
- Sexuality
- Soccer
- Social
- Society
- Spirituality
- Sports
- Stand-Up
- Stories
- Swimming
- TV
- Tabletop
- Technology
- Tennis
- Travel
- True Crime
- Episode-Games
- Visual
- Volleyball
- Weather
- Wilderness
- Wrestling
- Other
He contratado un rack y ¿ahora cómo me conecto?
Eres una empresa que has ido creciendo y necesitas contratar un rack en un centro de datos para poder ahí los servidores de tu empresa y dar servicio. ¿Qué posibilidades tienes para darle conectividad a ese rack? porque es obvio que vas a necesitar algún tipo de conectividad, si contratas un rack, unas Us o incluso una sala vas a querer conectarte a ella de alguna manera. Este tema quería tratarlo en un hilo de Twitter, pero claro, según iba pensando se me disparaban las posibilidades, así que este capítulo de hoy es un hilo de Twitter que bien ha merecido su propio audio en el podcast. De hecho el hilo en cuestión se me escapó a medio escribir y me lo tuve que cargar. Lo primero es decidir si la conectividad va a ser pública o no, porque no todos los racks están conectados al Internet público, algunos racks son simplemente cabinas de replicación, es decir, la replicación de una cabina que está en la oficina del cliente, para evitar desastres y cosas así. En este caso es posible que sólo queramos que la cabina sea accesible únicamente desde la oficina principal donde está la otra cabina, en este caso lo normal es contratar capacidad portadora, es decir, una conexión de 1 o 10G a un operador y que sea la únión del CPD con la oficina de la empresa. Si los requisitos son mayores siempre se puede poner una fibra oscura e iluminarla con SFPs de 40G o incluso meter CWDM o ¿por qué no? DWDM. Y si los requisitos son más sencillos a lo mejor con un túnel sobre internet puede servir, evidentemente depende muchísimo de los requisitos de cada cliente. También puede ser el caso que queramos tener la grabación de las cámaras de seguridad de una casa, aquí a lo mejor una VPN será suficiente. Depende en cada caso. Ahora, si queremos que los servicios se conecten a Internet tenemos dos opciones, tener direccionamiento propio con BGP o requerir direccionamiento del hoster. Sí, obviamente existe la posibilidad de tener direccionamiento propio pero no BGP, pero eso hablamos otro día porque no es lo normal. Si tienes direccionamiento público y AS lo ideal es levantar un par de sesiones BGP (al menos) con un par de routers y adelante. Si quieres direccionamiento del hoster pues tendrás que ponerte un gateway, que será un firewall, un router o similar y enrutar por ahí, obviamente el hoster también tiene que enrutar por ese equipo tu direccionamiento. Todo está está muy bien, pero seguro que no hay nada nuevo, la gracia de esto es ¿cómo pongo los cables? pues ahí es donde está la chicha de todo esto. Hay varias posibilidades, desde la más simple, en la cual le doy al cliente un único cable cable que une la plataforma del hoster con el firewall del cliente, el hoster configura una ruta al rango asignado al cliente hacia el firewall y el cliente una ruta por defecto a través de su firewall. Esta solución no es la mejor obviamente, para un servidor vale, pero para una infraestructura no es lo óptimo. A partir de aquí podemos complicar esto hasta el infinito dando más seguridad y más redundancia. Por ejemplo, si el cliente tiene un único firewall pero la posibilidad de tener dos uplinks podemos darle un LACP conectado a dos switches Nexus con VPC, de forma que si cayese un switch o uno de los cables el cliente seguiría funcionando por el otro cable, sin convergencias ni nada de nada porque el LACP seguiría funcionando, pero sólo por un puerto, cuando levantara de nuevo el enlace caído el LACP se volvería a formar con dos puertos. Esta solución es muy limpia y a mi personalmente me gusta, ¿cómo se configura? En el lado del hoster hay que configurar un LACP y una VLAN, y será esa VLAN la que pasemos por el LACP y el gateway para el cliente estará configurado en un interfaz VLAN que puede estar en ese mismo VPC, la pareja de switches, o en otro lado donde llegue la VLAN en cuestión. En el lado del cliente simplemente hay que configurar