Veremos como funciona Zabbix coa base de datos TimescaleDB como backend. Imos amosarche como comezar desde cero e como migrar desde PostgreSQL. Tamén proporcionaremos probas comparativas de rendemento das dúas configuracións.
HighLoad++ Siberia 2019. Salón Tomsk. 24 de xuño, 16:00 h. Teses e . A próxima conferencia HighLoad++ celebrarase os días 6 e 7 de abril de 2020 en San Petersburgo. Detalles e entradas .
Andrey Gushchin (en diante - AG): – Son enxeñeiro de soporte técnico de ZABBIX (en diante, “Zabbix”), un formador. Levo máis de 6 anos traballando no soporte técnico e teño experiencia directa co rendemento. Hoxe falarei sobre o rendemento que TimescaleDB pode proporcionar en comparación co PostgreSQL 10 normal. Ademais, algunha parte introdutoria sobre como funciona en xeral.
Principais desafíos de produtividade: desde a recollida de datos ata a limpeza de datos
Para comezar, hai certos desafíos de rendemento aos que se enfronta todo sistema de monitorización. O primeiro reto de produtividade é recoller e procesar datos rapidamente.
Un bo sistema de vixilancia debería recibir todos os datos de forma rápida e oportuna, procesalos segundo expresións desencadenantes, é dicir, procesalos segundo algúns criterios (isto é diferente en diferentes sistemas) e gardalos nunha base de datos para poder utilizar estes datos no futuro.
O segundo desafío de rendemento é o almacenamento do historial. Almacene a miúdo nunha base de datos e teña acceso rápido e cómodo a estas métricas que se recolleron durante un período de tempo. O máis importante é que estes datos sexan cómodos de obter, utilizalos en informes, gráficos, disparadores, nalgúns valores de limiar, para alertas, etc.
O terceiro reto de rendemento é o borrado do historial, é dicir, cando chegas ao punto no que non necesitas almacenar ningunha métrica detallada que se recolleu durante 5 anos (mesmo ou dous meses). Elimináronse algúns nodos de rede ou algúns anfitrións, as métricas xa non son necesarias porque xa están desactualizadas e xa non se recollen. Todo isto debe ser limpo para que a súa base de datos non creza demasiado. En xeral, borrar o historial é a maioría das veces unha proba seria para o almacenamento; moitas veces ten un impacto moi forte no rendemento.
Como resolver problemas de caché?
Agora falarei específicamente de Zabbix. En Zabbix, a primeira e a segunda chamadas resólvense usando a caché.
Recollida e procesamento de datos - Usamos RAM para almacenar todos estes datos. Estes datos agora serán discutidos con máis detalle.
Tamén no lado da base de datos hai algún almacenamento en caché para as seleccións principais - para gráficos e outras cousas.
Almacenamento na caché do propio servidor Zabbix: temos ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Que é?
ConfigurationCache é a caché principal na que almacenamos métricas, hosts, elementos de datos, disparadores; todo o que precisa para procesar o preprocesamento, recoller datos, de que hosts recoller, con que frecuencia. Todo isto gárdase en ConfigurationCache para non ir á base de datos e crear consultas innecesarias. Despois de que se inicie o servidor, actualizamos esta caché (creámola) e actualizamos periodicamente (dependendo da configuración).
Almacenamento na caché en Zabbix. Recollida de datos
Aquí o diagrama é bastante grande:
Os principais do esquema son estes colectores:
Estes son os propios procesos de montaxe, varios “pollers” que se encargan de diferentes tipos de montaxes. Recollen datos a través de icmp, ipmi e varios protocolos e transfiren todo ao preprocesamento.
Caché do historial de preprocesamento
Ademais, se temos elementos de datos calculados (saben os que estean familiarizados con Zabbix), é dicir, elementos de datos de agregación calculados, tomámolos directamente de ValueCache. Xa vos contarei como se enche máis tarde. Todos estes recolectores usan ConfigurationCache para recibir os seus traballos e despois pasalos ao preprocesamento.
O preprocesamento tamén usa ConfigurationCache para obter pasos de preprocesamento e procesa estes datos de varias maneiras. A partir da versión 4.2, movémolo a un proxy. Isto é moi cómodo, porque o preprocesamento en si é unha operación bastante difícil. E se tes un Zabbix moi grande, cunha gran cantidade de elementos de datos e unha alta frecuencia de recollida, isto simplifica moito o traballo.
En consecuencia, despois de que procesemos estes datos dalgún xeito mediante o preprocesamento, gardámolos en HistoryCache para procesalos máis. Isto conclúe a recollida de datos. Pasamos ao proceso principal.
Traballo de sincronizador histórico
O proceso principal en Zabbix (xa que é unha arquitectura monolítica) é History syncer. Este é o proceso principal que trata especificamente do procesamento atómico de cada elemento de datos, é dicir, de cada valor:
- o valor vén (lévao de HistoryCache);
- comproba no Sincronizador de configuración: se hai algún disparador para o cálculo - calcúlaos;
se hai - crea eventos, crea unha escalada para crear unha alerta, se é necesario segundo a configuración; - rexistros disparadores para o procesamento posterior, a agregación; se agregas durante a última hora e así por diante, ValueCache lembra este valor para non ir á táboa do historial; Así, o ValueCache énchese cos datos necesarios que son necesarios para calcular disparadores, elementos calculados, etc.;
- entón History syncer escribe todos os datos na base de datos;
- a base de datos escríbeos no disco - aquí remata o proceso de procesamento.
Base de datos. Almacenamento en caché
No lado da base de datos, cando queres ver gráficos ou algúns informes sobre eventos, hai varios cachés. Pero neste informe non vou falar deles.
Para MySQL hai Innodb_buffer_pool, e unha morea de cachés diferentes que tamén se poden configurar.
Pero estes son os principais:
- buffers_compartidos;
- tamaño_caché_efectivo;
- pool_compartido.
Para todas as bases de datos, dixen que hai certos cachés que permiten almacenar na memoria RAM os datos que adoitan ser necesarios para as consultas. Teñen as súas propias tecnoloxías para iso.
Acerca do rendemento da base de datos
En consecuencia, existe un ambiente competitivo, é dicir, o servidor Zabbix recolle datos e rexistraos. Cando se reinicia, tamén le do historial para encher o ValueCache e así por diante. Aquí podes ter scripts e informes que usan a API de Zabbix, que está construída nunha interface web. Zabbix API entra na base de datos e recibe os datos necesarios para obter gráficos, informes ou algún tipo de lista de eventos, problemas recentes.
Tamén unha solución de visualización moi popular é Grafana, que usan os nosos usuarios. Pode iniciar sesión directamente tanto a través da API de Zabbix como a través da base de datos. Tamén crea unha certa competencia para a obtención de datos: é necesario un axuste máis fino e mellor da base de datos para cumprir coa entrega rápida de resultados e probas.
Borrando o historial. Zabbix ten ama de casa
A terceira chamada que se usa en Zabbix é borrar o historial usando Housekeeper. Housekeeper segue todas as configuracións, é dicir, os nosos elementos de datos indican canto tempo almacenar (en días), canto tempo almacenar tendencias e a dinámica dos cambios.
Non falei de TrendCache, que calculamos sobre a marcha: chegan os datos, agregámolos durante unha hora (a maioría son números da última hora), a cantidade é media/mínima e rexistrámola unha vez por hora no táboa da dinámica de cambios (“Tendencias”) . "Housekeeper" inicia e elimina datos da base de datos mediante seleccións habituais, o que non sempre é efectivo.
Como entender que é ineficaz? Podes ver a seguinte imaxe nos gráficos de rendemento dos procesos internos:
O teu sincronizador do teu historial está constantemente ocupado (gráfico vermello). E o gráfico "vermello" que vai enriba. Este é un "Housekeeper" que se inicia e espera a que a base de datos elimine todas as filas que especificou.
Tomemos algún ID de elemento: cómpre eliminar os últimos 5 mil; por suposto, por índices. Pero normalmente o conxunto de datos é bastante grande: a base de datos aínda o le desde o disco e insérvao na caché, e esta é unha operación moi cara para a base de datos. Dependendo do seu tamaño, isto pode provocar certos problemas de rendemento.
Podes desactivar Housekeeper dun xeito sinxelo: temos unha interface web coñecida. A configuración en Administración xeral (configuración de "Agente do fogar") desactivamos o servizo doméstico interno para o historial interno e as tendencias. En consecuencia, a gobernadora xa non controla isto:
Que podes facer despois? Desactivaches, as túas gráficas niveláronse... Que máis problemas poderían xurdir neste caso? Que pode axudar?
Partición (sección)
Normalmente, isto está configurado dun xeito diferente en cada base de datos relacional que enumerei. MySQL ten a súa propia tecnoloxía. Pero en xeral son moi similares cando se trata de PostgreSQL 10 e MySQL. Por suposto, hai moitas diferenzas internas na forma en que se implementa todo e como afecta todo o rendemento. Pero, en xeral, a creación dunha nova partición moitas veces tamén leva a certos problemas.
Dependendo da súa configuración (cantos datos crea nun día), adoitan establecer o mínimo: isto é 1 día / lote, e para "tendencias", dinámica de cambios - 1 mes / novo lote. Isto pode cambiar se tes unha configuración moi grande.
Digamos de inmediato sobre o tamaño da configuración: ata 5 mil novos valores por segundo (os chamados nvps) - esta será considerada unha pequena "configuración". Media: de 5 a 25 mil valores por segundo. Todo o que está arriba son xa grandes instalacións e moi grandes que requiren unha configuración moi coidadosa da base de datos.
En instalacións moi grandes, 1 día pode non ser o ideal. Persoalmente vin particións en MySQL de 40 gigabytes por día (e pode haber máis). Esta é unha cantidade moi grande de datos, o que pode provocar algúns problemas. Hai que reducilo.
Por que necesitas partición?
O que ofrece o particionamento, creo que todo o mundo sabe, é o particionamento de táboas. Moitas veces estes son ficheiros separados no disco e solicitudes de extensión. Selecciona unha partición de forma máis óptima se forma parte da partición normal.
Para Zabbix, en particular, úsase por rango, por rango, é dicir, usamos unha marca de tempo (un número regular, tempo desde o inicio da época). Vostede especifica o inicio do día/fin do día, e esta é a partición. En consecuencia, se está a pedir datos que teñen dous días de antigüidade, todo se recupera da base de datos máis rápido, porque só precisa cargar un ficheiro na caché e devolvelo (en lugar dunha táboa grande).
Moitas bases de datos tamén aceleran a inserción (inserción nunha táboa filla). De momento falo en abstracto, pero tamén é posible. A partición moitas veces axuda.
Elasticsearch para NoSQL
Recentemente, en 3.4, implementamos unha solución NoSQL. Engadida a posibilidade de escribir en Elasticsearch. Podes escribir certos tipos: ti elixes: escribe números ou algúns signos; temos texto de cadea, podes escribir rexistros en Elasticsearch... En consecuencia, a interface web tamén accederá a Elasticsearch. Isto funciona moi ben nalgúns casos, pero de momento pódese usar.
TimecaleDB. Hipertáboas
Para 4.4.2 prestamos atención a unha cousa como TimescaleDB. Que é? Esta é unha extensión para PostgreSQL, é dicir, ten unha interface nativa de PostgreSQL. Ademais, esta extensión permítelle traballar de forma moito máis eficiente con datos de series temporais e ter partición automática. Como se ve:
Isto é hipertábel: hai tal concepto en Timescale. Esta é unha hipertáboa que creas e contén anacos. Os anacos son particións, estas son táboas fillas, se non me equivoco. É realmente eficaz.
TimescaleDB e PostgreSQL
Como aseguran os fabricantes de TimescaleDB, usan un algoritmo máis correcto para procesar consultas, en particular insercións, que lles permite ter un rendemento aproximadamente constante cun tamaño crecente da inserción do conxunto de datos. É dicir, despois de 200 millóns de filas de Postgres, o habitual comeza a caer moito e perde o seu rendemento literalmente a cero, mentres que Timescale permite inserir insercións da forma máis eficiente posible con calquera cantidade de datos.
Como instalar TimescaleDB? É sinxelo!
Está na documentación, descríbese: podes instalalo desde paquetes para calquera... Depende dos paquetes oficiais de Postgres. Pódese compilar manualmente. Ocorreu que tiven que compilar para a base de datos.
En Zabbix simplemente activamos a extensión. Creo que os que usaron Extention en Postgres... Simplemente activas Extention, créao para a base de datos Zabbix que estás a usar.
E o último paso...
TimecaleDB. Migración de táboas de historial
Debes crear unha hipertáboa. Hai unha función especial para iso: Crear hipertabla. Nela, o primeiro parámetro é a táboa que se necesita nesta base de datos (para a que cómpre crear unha hipertáboa).
O campo polo que se crea e chunk_time_interval (este é o intervalo de anacos (particións que se deben usar). 86 é un día.
Parámetro Migrate_data: se insire a verdadeiro, isto migrará todos os datos actuais a anacos creados previamente.
Eu mesmo usei migrate_data; leva bastante tempo, dependendo do grande que sexa a túa base de datos. Tiña máis dun terabyte: tardou máis dunha hora en crear. Nalgúns casos, durante as probas, eliminei os datos históricos para o texto (history_text) e a cadea (history_str) para non transferilos; non eran realmente interesantes para min.
E facemos a última actualización na nosa db_extention: instalamos timescaledb para que a base de datos e, en particular, o noso Zabbix entenda que existe db_extention. Actívao e utiliza a sintaxe e as consultas correctas na base de datos, utilizando aquelas "funcións" que son necesarias para TimescaleDB.
Configuración do servidor
Usei dous servidores. O primeiro servidor é unha máquina virtual bastante pequena, 20 procesadores, 16 gigabytes de RAM. Configurei Postgres 10.8 nel:
O sistema operativo era Debian, o sistema de ficheiros era xfs. Fixen unha configuración mínima para usar esta base de datos en particular, menos o que usará o propio Zabbix. Na mesma máquina había un servidor Zabbix, PostgreSQL e axentes de carga.
Usei 50 axentes activos que usan LoadableModule para xerar rapidamente diferentes resultados. Eles son os que xeraron as cadeas, os números, etc. Enchei a base de datos con moitos datos. Inicialmente, a configuración contiña 5 mil elementos de datos por host, e aproximadamente cada elemento de datos contiña un disparador, para que esta fose unha configuración real. Ás veces incluso necesitas máis dun disparador para usar.
Regulei o intervalo de actualización e a propia carga non só utilizando 50 axentes (engadindo máis), senón tamén utilizando elementos de datos dinámicos e reducindo o intervalo de actualización a 4 segundos.
Proba de rendemento. PostgreSQL: 36 mil NVP
O primeiro lanzamento, a primeira configuración que tiven foi en PostreSQL 10 puro neste hardware (35 mil valores por segundo). En xeral, como podes ver na pantalla, inserir datos leva fraccións de segundo: todo é bo e rápido, unidades SSD (200 gigabytes). O único é que 20 GB enchen bastante rápido.
Haberá moitos gráficos deste tipo no futuro. Este é un panel estándar de rendemento do servidor Zabbix.
O primeiro gráfico é o número de valores por segundo (azul, arriba á esquerda), 35 mil valores neste caso. Isto (arriba no centro) é a carga de procesos de compilación, e isto (arriba á dereita) é a carga de procesos internos: sincronizadores de historial e empregada do fogar, que aquí (abaixo no centro) leva en execución bastante tempo.
Este gráfico (abaixo ao centro) mostra o uso de ValueCache: cantas visitas de ValueCache para disparadores (varios miles de valores por segundo). Outro gráfico importante é o cuarto (abaixo á esquerda), que mostra o uso de HistoryCache, do que vos falei, que é un búfer antes de inserilo na base de datos.
Proba de rendemento. PostgreSQL: 50 mil NVP
A continuación, aumentei a carga a 50 mil valores por segundo no mesmo hardware. Cando cargado por Housekeeper, 10 mil valores foron rexistrados en 2-3 segundos con cálculo. O que, de feito, se mostra na seguinte captura de pantalla:
"Housekeeper" xa comeza a interferir no traballo, pero, en xeral, a carga dos tramperos con sumidoiros históricos aínda está no nivel do 60% (terceiro gráfico, arriba á dereita). HistoryCache xa comeza a encherse activamente mentres Housekeeper está en execución (abaixo á esquerda). Estaba preto de medio gigabyte, un 20 % cheo.
Proba de rendemento. PostgreSQL: 80 mil NVP
Entón aumenteino a 80 mil valores por segundo:
Foron aproximadamente 400 mil elementos de datos, 280 mil disparadores. A inserción, como podedes ver, en canto á carga de sumidoiros históricos (eran 30) xa era bastante alta. A continuación, aumentei varios parámetros: sumidoiros de historial, caché... Neste hardware, a carga dos sumidoiros de historial comezou a aumentar ata o máximo, case "no estante"; en consecuencia, HistoryCache entrou nunha carga moi alta:
Durante todo este tempo monitorei todos os parámetros do sistema (como se usa o procesador, RAM) e descubrín que a utilización do disco era máxima: conseguín a capacidade máxima deste disco neste hardware, nesta máquina virtual. "Postgres" comezou a volcar datos de forma bastante activa a tal intensidade, e o disco xa non tiña tempo para escribir, ler...
Tomei outro servidor que xa tiña 48 procesadores e 128 gigabytes de RAM:
Tamén o "axustei": instalei o sincronizador de historial (60 pezas) e conseguín un rendemento aceptable. De feito, non estamos "no andel", pero este é probablemente o límite da produtividade, onde xa é necesario facer algo ao respecto.
Proba de rendemento. TimescaleDB: 80 mil NVP
A miña tarefa principal foi usar TimescaleDB. Cada gráfico mostra un descenso:
Estes fallos son precisamente a migración de datos. Despois diso, no servidor Zabbix, o perfil de carga dos sinkers de historia, como podes ver, cambiou moito. Permítelle inserir datos case 3 veces máis rápido e usar menos HistoryCache; en consecuencia, recibirá os datos a tempo. De novo, 80 mil valores por segundo é unha taxa bastante alta (por suposto, non para Yandex). En xeral, esta é unha configuración bastante grande, cun servidor.
Proba de rendemento de PostgreSQL: 120 mil NVP
A continuación, aumentei o valor do número de elementos de datos a medio millón e recibín un valor calculado de 125 mil por segundo:
E teño estes gráficos:
En principio, esta é unha configuración que funciona, pode funcionar durante bastante tempo. Pero como só tiña un disco de 1,5 terabytes, useino nun par de días. O máis importante é que ao mesmo tempo creáronse novas particións en TimescaleDB, e isto pasou completamente desapercibido para o rendemento, o que non se pode dicir sobre MySQL.
Normalmente, as particións créanse pola noite, porque isto xeralmente bloquea a inserción e o traballo con táboas e pode provocar unha degradación do servizo. Neste caso non é así! A tarefa principal foi probar as capacidades de TimescaleDB. O resultado foi a seguinte cifra: 120 mil valores por segundo.
Tamén hai exemplos na comunidade:
A persoa tamén activou TimescaleDB e a carga de usar io.weight caeu no procesador; e tamén diminuíu o uso de elementos do proceso interno debido á inclusión de TimescaleDB. Ademais, estes son discos de panqueca comúns, é dicir, unha máquina virtual común en discos comúns (non SSD)!
Para algunhas pequenas configuracións que están limitadas polo rendemento do disco, TimescaleDB, na miña opinión, é unha solución moi boa. Permitirache seguir traballando antes de migrar a un hardware máis rápido para a base de datos.
Convídovos a todos aos nosos eventos: Conferencia en Moscova, Cumio en Riga. Use as nosas canles: Telegram, foro, IRC. Se tes algunha dúbida, ven á nosa mesa, podemos falar de todo.
Preguntas do público
Pregunta da audiencia (en diante - A): - Se TimescaleDB é tan fácil de configurar e dá un impulso de rendemento, entón quizais debería usarse como mellor práctica para configurar Zabbix con Postgres? E hai algún inconveniente e desvantaxe desta solución ou, ao cabo, se decidín facer Zabbix por min mesmo, podo tomar facilmente Postgres, instalar Timescale alí de inmediato, usalo e non pensar en ningún problema?
AG: – Si, diría que esta é unha boa recomendación: use Postgres inmediatamente coa extensión TimescaleDB. Como xa dixen, moitas boas críticas, a pesar de que esta "función" é experimental. Pero en realidade as probas demostran que esta é unha gran solución (con TimescaleDB) e creo que evolucionará. Estamos supervisando como se desenvolve esta extensión e faremos os cambios necesarios.
Mesmo durante o desenvolvemento, confiamos nunha das súas coñecidas "características": era posible traballar con anacos dun xeito un pouco diferente. Pero despois cortárono na seguinte versión e tivemos que deixar de confiar neste código. Recomendaría usar esta solución en moitas configuracións. Se usas MySQL... Para configuracións medias, calquera solución funciona ben.
R: – Nas últimas gráficas da comunidade, había unha gráfica con “Housekeeper”:
Seguiu traballando. Que fai Housekeeper con TimescaleDB?
AG: - Agora non podo dicir con certeza - mirarei o código e contarei con máis detalle. Usa consultas TimescaleDB non para eliminar anacos, senón para agregalos dalgún xeito. Aínda non estou preparado para responder a esta pregunta técnica. Descubriremos máis no stand hoxe ou mañá.
R: – Teño unha pregunta semellante – sobre o rendemento da operación de eliminación en Timecale.
R (resposta da audiencia): – Cando eliminas datos dunha táboa, se o fas mediante borrar, entón tes que pasar pola táboa: borrar, limpar, marcar todo para o baleiro futuro. En Timecale, xa que tes anacos, podes soltar. En liñas xerais, simplemente di ao ficheiro que está en big data: "Eliminar!"
Timescale simplemente entende que tal anaco xa non existe. E dado que está integrado no planificador de consultas, usa ganchos para detectar as túas condicións en operacións seleccionadas ou noutras e inmediatamente entende que este anaco xa non existe: "Non vou máis alí!" (datos non dispoñibles). Iso é todo! É dicir, unha exploración da táboa substitúese por unha eliminación de ficheiros binarios, polo que é rápido.
R: – Xa tocamos o tema do non-SQL. Polo que entendo, Zabbix non precisa modificar os datos, e todo isto é algo así como un rexistro. É posible utilizar bases de datos especializadas que non poden cambiar os seus datos, pero ao mesmo tempo gardar, acumular e distribuír moito máis rápido - Clickhouse, por exemplo, algo parecido a Kafka?... Kafka tamén é un rexistro! É posible integralos dalgún xeito?
AG: - Pódese facer a descarga. Temos unha certa "función" desde a versión 3.4: pode escribir todos os ficheiros históricos, eventos, todo o demais en ficheiros; e despois envíao a calquera outra base de datos usando algún manejador. De feito, moitas persoas reelaboran e escriben directamente na base de datos. Sobre a marcha, os sinkers do historial escriben todo isto en ficheiros, xiran estes ficheiros, etc., e podes transferilo a Clickhouse. Non podo dicir sobre os plans, pero quizais continúe o soporte adicional para solucións NoSQL (como Clickhouse).
R: – En xeral, resulta que podes desfacerte por completo de postgres?
AG: – Por suposto, a parte máis difícil de Zabbix son as táboas históricas, que crean máis problemas e eventos. Neste caso, se non almacenas eventos durante moito tempo e almacenas o historial con tendencias nalgún outro almacenamento rápido, en xeral, creo que non haberá problemas.
R: – Podes estimar canto máis rápido funcionará todo se cambias a Clickhouse, por exemplo?
AG: -Non o probei. Creo que polo menos se poden conseguir os mesmos números de xeito sinxelo, dado que Clickhouse ten a súa propia interface, pero non podo dicir con certeza. É mellor probar. Todo depende da configuración: cantos hosts teñas, etc. Inserir é unha cousa, pero tamén necesitas recuperar estes datos: Grafana ou outra cousa.
R: – Entón, estamos a falar dunha loita igualitaria, e non da gran vantaxe destas rápidas bases de datos?
AG: – Creo que cando nos integremos haberá probas máis precisas.
R: – Onde foi o bo vello RRD? Que che fixo cambiar ás bases de datos SQL? Inicialmente, todas as métricas recolléronse en RRD.
AG: – Zabbix tiña RRD, quizais nunha versión moi antiga. Sempre houbo bases de datos SQL, un enfoque clásico. O enfoque clásico é MySQL, PostgreSQL (existen desde hai moito tempo). Case nunca usamos unha interface común para bases de datos SQL e RRD.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com