Veremos como o Zabbix funciona com o banco de dados TimescaleDB como backend. Mostraremos como começar do zero e como migrar do PostgreSQL. Também forneceremos testes comparativos de desempenho das duas configurações.
HighLoad++ Sibéria 2019. Tomsk Hall. 24 de junho, 16h. Teses e . A próxima conferência HighLoad++ será realizada nos dias 6 e 7 de abril de 2020 em São Petersburgo. Detalhes e ingressos .
Andrey Gushchin (doravante – AG): – Sou engenheiro de suporte técnico do ZABBIX (doravante denominado “Zabbix”), um treinador. Trabalho com suporte técnico há mais de 6 anos e tenho experiência direta com performance. Hoje falarei sobre o desempenho que o TimescaleDB pode fornecer quando comparado com o PostgreSQL 10 normal. Além disso, uma parte introdutória sobre como ele funciona em geral.
Principais desafios de produtividade: da coleta de dados à limpeza de dados
Para começar, existem certos desafios de desempenho que todo sistema de monitoramento enfrenta. O primeiro desafio de produtividade é coletar e processar dados rapidamente.
Um bom sistema de monitoramento deve receber todos os dados de forma rápida e oportuna, processá-los de acordo com expressões de gatilho, ou seja, processá-los de acordo com alguns critérios (isso é diferente em sistemas diferentes) e salvá-los em um banco de dados para utilizar esses dados no futuro.
O segundo desafio de desempenho é o armazenamento de histórico. Armazene em um banco de dados com frequência e tenha acesso rápido e conveniente a essas métricas que foram coletadas ao longo de um período de tempo. O mais importante é que esses dados sejam fáceis de obter, utilize-os em relatórios, gráficos, gatilhos, em alguns valores limite, para alertas, etc.
O terceiro desafio de desempenho é a limpeza do histórico, ou seja, quando você chega ao ponto em que não precisa armazenar nenhuma métrica detalhada que tenha sido coletada ao longo de 5 anos (mesmo meses ou dois meses). Alguns nós da rede foram excluídos, ou alguns hosts, as métricas não são mais necessárias porque já estão desatualizadas e não são mais coletadas. Tudo isso precisa ser limpo para que seu banco de dados não cresça muito. Em geral, limpar o histórico costuma ser um teste sério para o armazenamento - geralmente tem um impacto muito forte no desempenho.
Como resolver problemas de cache?
Falarei agora especificamente sobre o Zabbix. No Zabbix, a primeira e a segunda chamadas são resolvidas usando cache.
Coleta e processamento de dados - Usamos RAM para armazenar todos esses dados. Esses dados serão agora discutidos com mais detalhes.
Também no lado do banco de dados há cache para seleções principais - para gráficos e outras coisas.
Cache na lateral do próprio servidor Zabbix: temos ConfigurationCache, ValueCache, HistoryCache, TrendsCache. O que é isso?
ConfigurationCache é o cache principal no qual armazenamos métricas, hosts, itens de dados, gatilhos; tudo que você precisa para processar o pré-processamento, coletar dados, de quais hosts coletar, com que frequência. Tudo isso fica armazenado no ConfigurationCache para não ir ao banco de dados e criar consultas desnecessárias. Após a inicialização do servidor, atualizamos esse cache (criamos) e o atualizamos periodicamente (dependendo das configurações).
Cache no Zabbix. Coleção de dados
Aqui o diagrama é bastante grande:
Os principais do esquema são estes coletores:
Estes são os próprios processos de montagem, vários “pesquisadores” responsáveis por diferentes tipos de montagens. Eles coletam dados via icmp, ipmi e vários protocolos e transferem tudo para pré-processamento.
Pré-processamento HistoryCache
Além disso, se tivermos elementos de dados calculados (aqueles que estão familiarizados com o Zabbix sabem), ou seja, elementos de dados de agregação calculados, nós os retiramos diretamente do ValueCache. Vou te contar como é preenchido mais tarde. Todos esses coletores usam o ConfigurationCache para receber seus trabalhos e depois passá-los para pré-processamento.
O pré-processamento também usa o ConfigurationCache para obter etapas de pré-processamento e processar esses dados de diversas maneiras. A partir da versão 4.2, mudamos para um proxy. Isto é muito conveniente porque o pré-processamento em si é uma operação bastante difícil. E se você tiver um Zabbix muito grande, com um grande número de elementos de dados e uma alta frequência de coleta, isso simplifica bastante o trabalho.
Conseqüentemente, depois de processarmos esses dados de alguma forma usando o pré-processamento, nós os salvamos no HistoryCache para processá-los posteriormente. Isso conclui a coleta de dados. Passamos para o processo principal.
Trabalho do sincronizador de histórico
O principal processo no Zabbix (por ser uma arquitetura monolítica) é o sincronizador de histórico. Este é o processo principal que trata especificamente do processamento atômico de cada elemento de dados, ou seja, de cada valor:
- vem o valor (leva do HistoryCache);
- verifica no Sincronizador de configuração: se existem gatilhos para cálculo - calcula-os;
se houver - cria eventos, cria escalonamento para criar alerta, se necessário conforme configuração; - registra gatilhos para processamento posterior, agregação; se agregar na última hora e assim por diante, esse valor é lembrado pelo ValueCache para não ir para a tabela de histórico; Assim, o ValueCache é preenchido com os dados necessários para calcular gatilhos, elementos calculados, etc.;
- então o sincronizador de histórico grava todos os dados no banco de dados;
- o banco de dados os grava no disco - é aqui que termina o processo de processamento.
Base de dados. Cache
Do lado do banco de dados, quando você deseja visualizar gráficos ou alguns relatórios de eventos, existem vários caches. Mas neste relatório não falarei sobre eles.
Para MySQL existe Innodb_buffer_pool e vários caches diferentes que também podem ser configurados.
Mas estes são os principais:
- buffers_compartilhados;
- tamanho_de_cache_efetivo;
- pool_compartilhado.
Para todos os bancos de dados, eu disse que existem certos caches que permitem armazenar na RAM os dados que muitas vezes são necessários para consultas. Eles têm suas próprias tecnologias para isso.
Sobre o desempenho do banco de dados
Dessa forma, existe um ambiente competitivo, ou seja, o servidor Zabbix coleta dados e os registra. Quando reiniciado, ele também lê o histórico para preencher o ValueCache e assim por diante. Aqui você pode ter scripts e relatórios que utilizam a API Zabbix, que é construída em uma interface web. A API do Zabbix entra no banco de dados e recebe os dados necessários para obter gráficos, relatórios, ou algum tipo de lista de eventos, problemas recentes.
Também uma solução de visualização muito popular é o Grafana, que nossos usuários usam. Capaz de fazer login diretamente através da API Zabbix e através do banco de dados. Também cria uma certa competição pela obtenção de dados: é necessário um ajuste mais fino e melhor do banco de dados para atender à entrega rápida de resultados e testes.
Limpando histórico. Zabbix tem governanta
A terceira chamada usada no Zabbix é limpar o histórico usando o Housekeeper. O Housekeeper acompanha todas as configurações, ou seja, nossos elementos de dados indicam quanto tempo armazenar (em dias), quanto tempo armazenar tendências e a dinâmica das mudanças.
Não falei do TrendCache, que calculamos na hora: os dados chegam, agregamos por uma hora (na maioria são números da última hora), o valor é médio/mínimo e registramos uma vez por hora no tabela da dinâmica das mudanças (“Tendências”) . “Housekeeper” inicia e exclui dados do banco de dados usando seleções regulares, o que nem sempre é eficaz.
Como entender que é ineficaz? Você pode ver a seguinte imagem nos gráficos de desempenho dos processos internos:
Seu sincronizador de histórico está constantemente ocupado (gráfico vermelho). E o gráfico “vermelho” que fica no topo. Este é um “Governante” que inicia e espera que o banco de dados exclua todas as linhas que ele especificou.
Vejamos alguns IDs de itens: você precisa deletar os últimos 5 mil; claro, por índices. Mas geralmente o conjunto de dados é bastante grande - o banco de dados ainda o lê do disco e o coloca no cache, e esta é uma operação muito cara para o banco de dados. Dependendo do seu tamanho, isso pode levar a certos problemas de desempenho.
Você pode desativar o Housekeeper de uma forma simples - temos uma interface web familiar. Configurações em Administração geral (configurações para “Governante”) desativamos a limpeza interna para histórico interno e tendências. Conseqüentemente, a Governanta não controla mais isso:
O que você pode fazer a seguir? Você desligou, seus gráficos ficaram nivelados... Que outros problemas poderiam surgir neste caso? O que pode ajudar?
Particionamento (seccionamento)
Normalmente, isso é configurado de maneira diferente em cada banco de dados relacional listado. MySQL possui sua própria tecnologia. Mas no geral eles são muito semelhantes quando se trata de PostgreSQL 10 e MySQL. É claro que existem muitas diferenças internas na forma como tudo é implementado e como tudo afeta o desempenho. Mas, em geral, a criação de uma nova partição muitas vezes também leva a certos problemas.
Dependendo da sua configuração (quantos dados você cria em um dia), eles geralmente definem o mínimo - é 1 dia/lote, e para “tendências”, dinâmica de mudanças - 1 mês/novo lote. Isso pode mudar se você tiver uma configuração muito grande.
Digamos imediatamente sobre o tamanho da configuração: até 5 mil novos valores por segundo (os chamados nvps) - isso será considerado uma pequena “configuração”. Média – de 5 a 25 mil valores por segundo. Tudo o que está acima já são instalações grandes e muito grandes que exigem uma configuração muito cuidadosa do banco de dados.
Em instalações muito grandes, 1 dia pode não ser o ideal. Eu pessoalmente vi partições no MySQL de 40 gigabytes por dia (e pode haver mais). Esta é uma quantidade muito grande de dados, o que pode levar a alguns problemas. Precisa ser reduzido.
Por que você precisa de particionamento?
O que o particionamento oferece, acho que todo mundo sabe, é o particionamento de tabelas. Freqüentemente, esses são arquivos separados em solicitações de disco e span. Ele seleciona uma partição de forma mais otimizada se fizer parte do particionamento normal.
Para o Zabbix, em particular, é utilizado por intervalo, por intervalo, ou seja, utilizamos um timestamp (um número regular, tempo desde o início da época). Você especifica o início/fim do dia e esta é a partição. Da mesma forma, se você estiver solicitando dados com dois dias de idade, tudo será recuperado do banco de dados mais rapidamente, porque você só precisa carregar um arquivo no cache e devolvê-lo (em vez de uma tabela grande).
Muitos bancos de dados também aceleram a inserção (inserção em uma tabela filho). Estou falando de forma abstrata por enquanto, mas isso também é possível. A partição geralmente ajuda.
Elasticsearch para NoSQL
Recentemente, na versão 3.4, implementamos uma solução NoSQL. Adicionada a capacidade de escrever no Elasticsearch. Você pode escrever certos tipos: você escolhe - escrever números ou alguns sinais; temos texto de string, você pode escrever logs no Elasticsearch... Assim, a interface da web também acessará o Elasticsearch. Isso funciona muito bem em alguns casos, mas no momento pode ser usado.
Escala de tempoDB. Hipertabelas
Para a versão 4.4.2, prestamos atenção em algo como TimescaleDB. O que é isso? Esta é uma extensão do PostgreSQL, ou seja, possui uma interface PostgreSQL nativa. Além disso, esta extensão permite que você trabalhe de forma muito mais eficiente com dados de séries temporais e tenha particionamento automático. O que isso parece:
Isso é hipertabela - existe esse conceito na escala de tempo. Esta é uma hipertabela que você cria e contém pedaços. Pedaços são partições, são tabelas filhas, se não me engano. É realmente eficaz.
TimescaleDB e PostgreSQL
Como garantem os fabricantes do TimescaleDB, eles usam um algoritmo mais correto para processar consultas, em particular inserções, o que permite um desempenho aproximadamente constante com um tamanho crescente da inserção do conjunto de dados. Ou seja, após 200 milhões de linhas do Postgres, o usual começa a ceder muito e perde desempenho literalmente a zero, enquanto o Timescale permite inserir inserções da forma mais eficiente possível com qualquer quantidade de dados.
Como instalar o TimescaleDB? É simples!
Está na documentação, está descrito - você pode instalá-lo a partir de pacotes para qualquer... Depende dos pacotes oficiais do Postgres. Pode ser compilado manualmente. Acontece que tive que compilar para o banco de dados.
No Zabbix simplesmente ativamos a Extensão. Acho que quem usou o Extention no Postgres... Você simplesmente ativa o Extention, cria ele para o banco de dados Zabbix que você está usando.
E o último passo...
Escala de tempoDB. Migração de tabelas de histórico
Você precisa criar uma hipertabela. Existe uma função especial para isso – Criar hipertabela. Nele, o primeiro parâmetro é a tabela necessária neste banco de dados (para a qual é necessário criar uma hipertabela).
O campo pelo qual criar e chunk_time_interval (este é o intervalo de pedaços (partições que precisam ser usadas). 86 é um dia.
Parâmetro Migrate_data: Se você inserir como true, isso migrará todos os dados atuais para blocos pré-criados.
Eu mesmo usei o Migrate_data - leva bastante tempo, dependendo do tamanho do seu banco de dados. Eu tinha mais de um terabyte – levei mais de uma hora para criar. Em alguns casos, durante o teste, excluí dados históricos de texto (history_text) e string (history_str) para não transferi-los - eles não eram realmente interessantes para mim.
E fazemos a última atualização em nosso db_extention: instalamos o timescaledb para que o banco de dados e, principalmente, nosso Zabbix entendam que existe db_extention. Ele o ativa e usa a sintaxe e consultas corretas ao banco de dados, usando os “recursos” necessários para o TimescaleDB.
Configuração do servidor
Usei dois servidores. O primeiro servidor é uma máquina virtual bastante pequena, 20 processadores e 16 gigabytes de RAM. Eu configurei o Postgres 10.8 nele:
O sistema operacional era o Debian, o sistema de arquivos era o xfs. Fiz configurações mínimas para usar esse banco de dados específico, menos o que o próprio Zabbix usará. Na mesma máquina havia um servidor Zabbix, PostgreSQL e agentes de carga.
Usei 50 agentes ativos que usam LoadableModule para gerar resultados diferentes rapidamente. Foram eles que geraram as strings, números e assim por diante. Enchi o banco de dados com muitos dados. Inicialmente, a configuração continha 5 mil elementos de dados por host, e aproximadamente cada elemento de dados continha um trigger - para que esta fosse uma configuração real. Às vezes você ainda precisa de mais de um gatilho para usar.
Regulei o intervalo de atualização e a própria carga não apenas usando 50 agentes (adicionando mais), mas também usando elementos de dados dinâmicos e reduzindo o intervalo de atualização para 4 segundos.
Teste de performance. PostgreSQL: 36 mil NVPs
O primeiro lançamento, o primeiro setup que tive foi em PostreSQL 10 puro neste hardware (35 mil valores por segundo). Em geral, como você pode ver na tela, a inserção de dados leva frações de segundo - tudo é bom e rápido, unidades SSD (200 gigabytes). A única coisa é que 20 GB são preenchidos rapidamente.
Haverá muitos desses gráficos no futuro. Este é um painel padrão de desempenho do servidor Zabbix.
O primeiro gráfico é o número de valores por segundo (azul, canto superior esquerdo), 35 mil valores neste caso. Este (parte superior central) é o carregamento dos processos de construção, e este (canto superior direito) é o carregamento dos processos internos: sincronizadores de histórico e governanta, que aqui (parte inferior central) está em execução há algum tempo.
Este gráfico (parte inferior central) mostra o uso do ValueCache - quantos acessos do ValueCache para gatilhos (vários milhares de valores por segundo). Outro gráfico importante é o quarto (canto inferior esquerdo), que mostra a utilização do HistoryCache, do qual falei, que é um buffer antes de inserir no banco de dados.
Teste de performance. PostgreSQL: 50 mil NVPs
Em seguida, aumentei a carga para 50 mil valores por segundo no mesmo hardware. Quando carregado pelo Housekeeper, 10 mil valores foram registrados em 2 a 3 segundos com cálculo. O que, de fato, é mostrado na imagem a seguir:
A “governanta” já começa a interferir no trabalho, mas em geral a carga sobre os caçadores de chumbadas históricas ainda está na casa dos 60% (terceiro gráfico, canto superior direito). O HistoryCache já começa a ser preenchido ativamente enquanto o Housekeeper está em execução (canto inferior esquerdo). Tinha cerca de meio gigabyte, 20% cheio.
Teste de performance. PostgreSQL: 80 mil NVPs
Depois aumentei para 80 mil valores por segundo:
Foram aproximadamente 400 mil elementos de dados, 280 mil gatilhos. O encarte, como vocês podem ver, em termos de carga de chumbadas históricas (eram 30) já era bastante alto. Então aumentei vários parâmetros: chumbadas de histórico, cache... Neste hardware, a carga nos chumbadas de histórico começou a aumentar ao máximo, quase “na prateleira” - conseqüentemente, o HistoryCache entrou em uma carga muito alta:
Todo esse tempo monitorei todos os parâmetros do sistema (como o processador é usado, RAM) e descobri que a utilização do disco era máxima - atingi a capacidade máxima desse disco neste hardware, nesta máquina virtual. O "Postgres" começou a despejar dados de forma bastante ativa com tal intensidade, e o disco não teve mais tempo para escrever, ler...
Peguei outro servidor que já tinha 48 processadores e 128 gigabytes de RAM:
Eu também “ajustei” - instalei o sincronizador de histórico (60 peças) e obtive um desempenho aceitável. Na verdade, não estamos “na prateleira”, mas este é provavelmente o limite da produtividade, onde já é necessário fazer algo a respeito.
Teste de performance. TimescaleDB: 80 mil NVPs
Minha principal tarefa era usar o TimescaleDB. Cada gráfico mostra uma queda:
Essas falhas são justamente a migração de dados. Depois disso, no servidor Zabbix, o perfil de carregamento dos chumbadores de histórico, como você pode ver, mudou bastante. Ele permite inserir dados quase 3 vezes mais rápido e usar menos HistoryCache - portanto, você terá os dados entregues no prazo. Novamente, 80 mil valores por segundo é uma taxa bastante alta (claro, não para Yandex). No geral, esta é uma configuração bastante grande, com um servidor.
Teste de desempenho PostgreSQL: 120 mil NVPs
Em seguida, aumentei o valor do número de elementos de dados para meio milhão e recebi um valor calculado de 125 mil por segundo:
E eu tenho esses gráficos:
Em princípio, esta é uma configuração funcional, pode funcionar por muito tempo. Mas como eu tinha apenas um disco de 1,5 terabyte, usei-o em alguns dias. O mais importante é que ao mesmo tempo foram criadas novas partições no TimescaleDB, e isso passou completamente despercebido pelo desempenho, o que não se pode dizer do MySQL.
Normalmente, as partições são criadas à noite, pois isso geralmente bloqueia a inserção e o trabalho com tabelas e pode levar à degradação do serviço. Neste caso não é esse o caso! A principal tarefa foi testar os recursos do TimescaleDB. O resultado foi o seguinte: 120 mil valores por segundo.
Também há exemplos na comunidade:
A pessoa também ativou o TimescaleDB e a carga do uso de io.weight caiu no processador; e o uso de elementos de processos internos também diminuiu devido à inclusão do TimescaleDB. Além disso, estes são discos panqueca comuns, ou seja, uma máquina virtual comum em discos comuns (não SSDs)!
Para algumas configurações pequenas limitadas pelo desempenho do disco, o TimescaleDB, na minha opinião, é uma solução muito boa. Isso permitirá que você continue trabalhando antes de migrar para um hardware mais rápido para o banco de dados.
Convido todos vocês para nossos eventos: Conferência em Moscou, Cúpula em Riga. Utilize nossos canais - Telegram, fórum, IRC. Se tiver alguma dúvida, venha até nossa mesa, podemos conversar sobre tudo.
Perguntas do público
Pergunta do público (doravante - A): - Se o TimescaleDB é tão fácil de configurar e oferece um grande aumento de desempenho, então talvez isso deva ser usado como uma prática recomendada para configurar o Zabbix com Postgres? E há alguma armadilha e desvantagem nessa solução, ou afinal, se eu decidir fazer o Zabbix para mim mesmo, posso facilmente pegar o Postgres, instalar o Timescale lá imediatamente, usá-lo e não pensar em problemas?
AG: – Sim, eu diria que esta é uma boa recomendação: usar imediatamente o Postgres com a extensão TimescaleDB. Como já disse, muitas críticas boas, apesar de esta “funcionalidade” ser experimental. Mas na verdade os testes mostram que esta é uma ótima solução (com TimescaleDB) e acho que vai evoluir! Estamos monitorando o desenvolvimento desta extensão e faremos alterações conforme necessário.
Mesmo durante o desenvolvimento, contamos com um de seus “recursos” bem conhecidos: era possível trabalhar com chunks de uma forma um pouco diferente. Mas então eles cortaram isso na próxima versão e tivemos que parar de confiar nesse código. Eu recomendaria usar esta solução em muitas configurações. Se você usa MySQL... Para configurações médias, qualquer solução funciona bem.
A: – Nos últimos gráficos da comunidade, havia um gráfico com “Governanta”:
Ele continuou trabalhando. O que o Housekeeper faz com o TimescaleDB?
AG: – Agora não posso dizer com certeza – vou olhar o código e contar com mais detalhes. Ele usa consultas TimescaleDB não para excluir pedaços, mas para agregá-los de alguma forma. Ainda não estou pronto para responder a essa pergunta técnica. Saberemos mais no estande hoje ou amanhã.
A: – Tenho uma pergunta semelhante – sobre o desempenho da operação de exclusão no Timescale.
A (resposta do público): – Quando você apaga dados de uma tabela, se fizer via delete, então você precisa passar pela tabela - deletar, limpar, marcar tudo para aspiração futura. Na escala de tempo, como você tem pedaços, você pode descartá-los. Grosso modo, basta dizer ao arquivo que está no big data: “Excluir!”
A escala de tempo simplesmente entende que tal pedaço não existe mais. E como está integrado ao planejador de consultas, ele usa ganchos para capturar suas condições em operações de seleção ou outras e entende imediatamente que esse pedaço não existe mais - “Não irei mais lá!” (dados não disponíveis). Isso é tudo! Ou seja, uma varredura de tabela é substituída por uma exclusão de arquivo binário, por isso é rápido.
A: – Já tocamos no tópico não-SQL. Pelo que entendi, o Zabbix realmente não precisa modificar os dados, e tudo isso é algo como um log. É possível usar bancos de dados especializados que não podem alterar seus dados, mas ao mesmo tempo salvar, acumular e distribuir muito mais rápido - Clickhouse, por exemplo, algo parecido com Kafka?.. Kafka também é um log! É possível integrá-los de alguma forma?
AG: - O descarregamento pode ser feito. Temos um certo “recurso” desde a versão 3.4: você pode gravar todos os arquivos históricos, eventos, tudo mais em arquivos; e envie-o para qualquer outro banco de dados usando algum manipulador. Na verdade, muitas pessoas retrabalham e escrevem diretamente no banco de dados. Imediatamente, os coletores de histórico gravam tudo isso em arquivos, giram esses arquivos e assim por diante, e você pode transferir isso para Clickhouse. Não posso falar sobre planos, mas talvez o suporte adicional para soluções NoSQL (como Clickhouse) continue.
A: – Em geral, acontece que você pode se livrar completamente do postgres?
AG: – Claro que a parte mais difícil no Zabbix são as tabelas históricas, que criam mais problemas, e eventos. Nesse caso, se você não armazenar eventos por muito tempo e armazenar o histórico com tendências em algum outro armazenamento rápido, então, em geral, acho que não haverá problemas.
A: – Você consegue estimar o quanto tudo funcionará mais rápido se você mudar para Clickhouse, por exemplo?
AG: – Eu não testei. Acho que pelo menos os mesmos números podem ser alcançados de forma bastante simples, visto que o Clickhouse possui interface própria, mas não posso afirmar com certeza. É melhor testar. Tudo depende da configuração: quantos hosts você possui e assim por diante. Inserir é uma coisa, mas você também precisa recuperar esses dados - Grafana ou outra coisa.
A: – Então estamos falando de uma luta igualitária, e não da grande vantagem desses bancos de dados rápidos?
AG: – Acho que quando integrarmos, haverá testes mais precisos.
A: – Para onde foi o bom e velho RRD? O que fez você mudar para bancos de dados SQL? Inicialmente, todas as métricas foram coletadas no RRD.
AG: – Zabbix tinha RRD, talvez em uma versão muito antiga. Sempre existiram bancos de dados SQL – uma abordagem clássica. A abordagem clássica é MySQL, PostgreSQL (eles já existem há muito tempo). Quase nunca usamos uma interface comum para bancos de dados SQL e RRD.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com