TL, RD: O equipo de Bloomberg Storage Engineering creou almacenamento na nube para uso interno que non interfire coa infraestrutura e pode soportar a gran carga da volatilidade das negociacións durante a pandemia.
Mattew Leonard, cando fala do seu traballo como xestor técnico no equipo de Enxeñaría de Almacenamento de Bloomberg, adoita empregar as palabras "desafiante" e "divertido". Os desafíos xorden da ampla gama de almacenamento, desde as últimas matrices SAN baseadas en NVMe ata o almacenamento definido por software de código aberto en DevOps. Aquí é onde comeza a "diversión" (ver o meu avatar en Habré, aprox. tradutor).
Leonard e o seu equipo de 25 colegas supervisan máis de 100 petabytes de capacidade e unha nube interna para 6000 enxeñeiros que desenvolven aplicacións para Bloomberg Terminal, a tecnoloxía que converteu a Michael Bloomberg en multimillonario. O equipo deseña, constrúe e mantén sistemas de almacenamento para Bloomberg Engineering.
Do mesmo xeito que o resto da profesión de TI, 2020 foi un ano inusual para os membros do equipo de Enxeñaría de Almacenamento xa que o COVID-19 obrigou a traballar a distancia. Leonard dixo que a pandemia afectara socialmente ao seu "equipo unido" xa que se eliminaron as interaccións cara a cara, pero o persoal adaptouse moi rapidamente para traballar desde casa en ordenadores portátiles e videoconferencia.
Sorprendentemente, quero dicir que isto non empeorou as cousas. Houbo un curto período de adaptación: non todos estaban preparados para traballar desde casa. Despois dunha ou dúas semanas, todos entenderon isto. Puidemos atopar formas de manternos ocupados, comprar e actualizar equipos e aumentar os custos para apoiar a empresa durante estes tempos. Tivemos que ser creativos, pero non saímos mal
O maior desafío puido ser anterior ao pico de COVID-19. Isto debeuse á volátil negociación do mercado debido á preocupación polo impacto da pandemia na economía global. O volume de datos que flúen aos terminais Bloomberg desde os mercados de capitais mundiais case se duplicou, chegando nalgúns días a finais de marzo aos 240 millóns de información. Esta é unha proba seria dos sistemas de almacenamento.
Cando duplicas ao instante os teus requisitos de almacenamento nun día, crea problemas interesantes. Puidemos superar isto e garantir que os equipos de desenvolvemento de aplicacións tiñan o espazo e o rendemento que necesitaban. A maior parte disto ten que ver coa forma en que pensamos nos sistemas de almacenamento. Hoxe non estamos creando nada. Non dicimos: "Usamos ABC, así que imos construír a infraestrutura para ABC". Facemos o que chamamos "orzamento de datos" cos nosos equipos para prever o uso, analizar as tendencias de uso e rendemento, e tamén miramos a seguridade. Este tipo de planificación, pensamento e debida dilixencia metódica permítenos tomar medidas drásticas ante os aumentos sen suar. Por suposto, estaba nervioso, pero sentíame cómodo estando no meu lugar.
Leonard falou recentemente con SearchStorage en detalle sobre a xestión do almacenamento para empresas baseadas en datos. Discutiu o que sería necesario ofrecer unha solución de almacenamento na nube privada, coa capacidade de proporcionar funcións de AWS aos seus usuarios mentres manteñen os datos nos centros de datos de Bloomberg.
Se xa non hai unha pandemia, que dificultades teñen os enxeñeiros de Bloomberg para xestionar o almacenamento?
Temos moitas necesidades, simplemente estamos desgarrados en diferentes direccións. Polo tanto, necesitamos ofrecer moitos tipos diferentes de produtos a diferentes niveis de SLA para axudar aos nosos desenvolvedores de aplicacións a centrarse nas súas tarefas en lugar de preocuparse polo propio almacenamento.
E que estratexia segues para iso?
Parte do que estamos tentando é mellorar o rendemento do almacenamento. Pense no modelo de AWS no que un enxeñeiro de desenvolvemento entra, preme un botón e, a continuación, "clic" obtén máxicamente o tipo de almacenamento axeitado para resolver o seu problema.
Como é a túa infraestrutura de almacenamento?
Como temos un ecosistema moi diverso e moitos desenvolvedores diferentes, non podemos ofrecer un só produto. Temos almacenamento de obxectos, ficheiros e bloques. Estes son produtos diferentes e ofrecemos diferentes tipos de tecnoloxías para entregalos. Para o bloque usamos SAN. Tamén temos SDS, que ofrece outra opción de almacenamento en bloque cun conxunto diferente de requisitos de rendemento. Para ficheiros usamos NFS. SDS tamén se usa para almacenar obxectos. O bloque e as partes do obxecto forman unha nube privada interna para computación e almacenamento.
Entón, non utiliza o almacenamento na nube pública?
Correcto. Algúns equipos de desenvolvemento teñen permiso para usar nubes públicas. Pero pola natureza do noso negocio, preferimos ter máis control sobre as cousas que deixan as nosas paredes. Entón, si, temos as nosas propias nubes que están baixo o noso control. Trátase de equipos situados no noso centro de datos baixo a nosa xestión.
Nos nosos centros de datos, preferimos unha estratexia de varios provedores. Son grandes provedores, pero non diremos quen exactamente (é a política de Bloomberg non avalar ningún provedor, aprox. tradutor).
Estás a usar infraestrutura hiperconverxente para crear a túa nube privada?
Non. En Bloomberg estamos elixindo unha dirección na que non avanzamos cara á hiperconverxencia. Estamos tentando desvincular a computación do almacenamento para poder escalalos de forma independente. A dirección na que nos movemos, especialmente coa nosa nube, é para que poidamos separar esas dúas entidades. E todo porque algunhas cousas no noso país requiren cálculos intensivos, mentres que outras requiren almacenamento. Se os escalas de forma uniforme, perderás recursos, sen importar diñeiro ou espazo nos centros de datos, ou comprando capacidade que non necesitas. É por iso que nos gusta ter unha interface común entre as dúas entidades, pero que sexan sistemas completamente diferentes e xestionados por equipos diferentes.
Que obstáculos hai que superar para construír unha nube privada?
Problema de escala. Como na maioría das cousas, o demo está nos detalles. Cando pensas en como funcionan estas cousas, como facelas resistentes, como manexar a carga operativa, como te comunicas cos equipos de activos físicos, as cousas vólvense un pouco interesantes. O reto é atopar unha forma de facer de todo un produto escalable e compatible que quererían utilizar os nosos desenvolvedores de aplicacións, podendo enriquecer o conxunto de funcións mentres se mantén á vangarda do que está a facer a nube pública. E tamén xuntalo todo para que siga funcionando. Este é o noso principal problema: traballamos en todas as áreas do negocio, intentando satisfacer todas as necesidades, pero sen ignorar outras necesidades.
Cres que necesitas as funcións máis recentes dispoñibles en AWS e outras nubes públicas?
O feito máis divertido de S3 é que o nivel de vida cambia constantemente, sempre se engaden novas funcións. É como un xoguete novo. Se alguén ve unha función nova nunha nova versión, quere. Non todas as funcións de AWS son aplicables no noso contorno, polo que é importante e interesante saber que axudarán aos desenvolvedores e como obtelo na propia casa.
Que equipos de almacenamento utilizas?
Usamos equipos de última xeración. A nosa nube interna está completamente baseada en NVMe Flash, o que fai que estes sistemas sexan moi potentes. Fainos a vida un pouco máis fácil e tamén é unha función agradable para os nosos desenvolvedores porque non teñen que preocuparse polo rendemento do almacenamento.
Para que usa o almacenamento de obxectos?
Temos 6000 desenvolvedores traballando na infraestrutura, non están unidos por ningún caso de uso. Calquera opción que se ocorra, probablemente a teñamos no almacenamento de obxectos. Algúns equipos úsano para almacenamento de arquivos en frío, algúns para transferencia de datos e outros que o usan para aplicacións transaccionais. Todos estes casos de uso requiren diferentes niveis de SLA, polo que, como podes ver, temos diferentes tipos de tráfico, todo tipo de necesidades para diferentes usuarios da nosa infraestrutura. Este non é un caso de uso homoxéneo que se executa enriba de ningún dos nosos almacenamentos, o que obviamente fai que as cousas sexan máis complexas.
Que papel xogan Kubernetes e os contedores para ti e como afecta isto ao almacenamento?
Estamos impulsando a produtividade do almacenamento para crear unha sensación de nube, unha sensación de algo como servizo, onde hai un botón para que os desenvolvedores aceleren a súa creación e eliminen infraestruturas ao longo do camiño.
Editor n.b.: 15 de outubro de 2020 estará listo . Aprenderá a tecnoloxía de almacenamento en rede Ceph para usar nos seus proxectos para mellorar a tolerancia a fallos.
Temos tres equipos, o primeiro é o equipo da API de almacenamento. Crean acceso programático, puntos finais e fluxos de traballo predefinidos para clientes de desenvolvemento de aplicacións en Bloomberg. Este é un equipo de desenvolvedores web full stack, empregan tecnoloxías de código aberto node.js, python, como Apache Airflow, polo que estudan a contenerización e a virtualización.
Tamén temos dous equipos técnicos que realmente moven os bits e os bytes. Están máis directamente relacionados co equipamento. Temos moitos equipos, e estes equipos non usan virtualización e contenedores.
Estamos tentando seguir o que está a suceder na industria, estudando os controladores CSI de Kubernetes e tamén traballando en estreita colaboración co equipo que implementa Kubernetes en Bloomberg para avaliar se podemos facer que o almacenamento de Kubernetes funcione de forma coherente coas tecnoloxías que temos. está funcionando. Usamos SDS para admitir Kubernetes conectado ao almacenamento persistente. Desenvolvemos con éxito esta tecnoloxía e continúan as discusións entre os dous equipos sobre como podemos facelo dispoñible para todos os demais en Bloomberg. Demostramos que isto é moi posible.
Que outro software de código aberto usas, especialmente para almacenar?
Usamos Apache Airflow, HAProxy para limitar o tráfico de aplicacións. Tamén usamos Ceph, unha plataforma para SDS. Con el, pode ter un sistema para comandos, pero proporcionar varias interfaces aos clientes. Unha das plataformas de virtualización funciona en OpenStack: traballamos en estreita colaboración con este equipo. Temos unha plataforma de virtualización de código aberto que usa a plataforma SDS de código aberto para o almacenamento. É divertido.
Que tecnoloxías de almacenamento está considerando para os próximos dous ou tres anos?
Sempre estamos a buscar outras cousas novas interesantes que suceden no sector do almacenamento. Isto é parte do noso traballo, non é "aquí está o teu SAN, xestiona aquí, e aquí está o teu NFS, xestiona alí". Tentamos comunicarnos cos nosos clientes, é dicir. polos nosos desenvolvedores de aplicacións. Traballamos xuntos para comprender cales son os problemas que intentan resolver e como afectará aos nosos clientes externos de Bloomberg: os bancos e outros que usan o noso software. E despois volvemos ao mundo do almacenamento de datos para atopar oportunidades que lles axuden a alcanzar o seu obxectivo. Como podemos axudalos a atopar a tecnoloxía de almacenamento adecuada que se axuste ao seu SLA ou ao que están intentando facer? Porque temos tantos enxeñeiros facendo cousas interesantes, nunca se aburre.
Actualmente estamos a buscar formas de mellorar o rendemento de SDS que poderían executarse en servidores de propósito xeral. Entón estamos traballando en NVMe sobre TCP, esta é unha iniciativa moi interesante e interesante, unha de moitas. Tamén estamos a traballar con persoas clave do sector e algúns dos provedores existentes para coñecer o que ofrecen e cal será o rendemento real, se podemos comezar a utilizalo na produción na empresa. Isto abre novos horizontes que antes non eran accesibles.
Un pouco de axuda en PS
PD Se me permite, lembrarvos que se celebrará do 28 ao 30 de setembro , para aqueles que non coñecen Kubernetes, pero queren familiarizarse con el e comezar a traballar con el.
Fonte: www.habr.com