Vi kommer att titta på hur Zabbix fungerar med TimescaleDB-databasen som backend. Vi visar dig hur du börjar från början och hur du migrerar från PostgreSQL. Vi kommer också att tillhandahålla jämförande prestandatester av de två konfigurationerna.
HighLoad++ Sibirien 2019. Tomsk Hall. 24 juni, 16:00. Avhandlingar och . Nästa HighLoad++-konferens kommer att hållas den 6 och 7 april 2020 i St. Petersburg. Detaljer och biljetter .
Andrey Gushchin (nedan – AG): – Jag är en ZABBIX teknisk supportingenjör (nedan kallad "Zabbix"), en utbildare. Jag har arbetat med teknisk support i mer än 6 år och har haft direkt erfarenhet av prestanda. Idag ska jag prata om prestandan som TimescaleDB kan ge jämfört med vanlig PostgreSQL 10. Dessutom en introduktionsdel om hur det fungerar i allmänhet.
Главные вызовы производительности: от сбора до очистки данных
Till att börja med finns det vissa prestandautmaningar som varje övervakningssystem står inför. Den första produktivitetsutmaningen är att snabbt samla in och bearbeta data.
Ett bra övervakningssystem bör snabbt, i tid ta emot all data, bearbeta den enligt triggeruttryck, det vill säga bearbeta den enligt vissa kriterier (detta är olika i olika system) och spara den i en databas för att kunna använda dessa data i framtida.
Второй вызов производительности – это хранение истории. Хранить в базе данных зачастую и иметь быстрый и удобный доступ к этим метрикам, которые были собраны за какой-то период времени. Самое главное, чтобы эти данные было удобно получить, использовать их в отчётах, графиках, триггерах, в каких-то пороговых значениях, для оповещений и т. д.
Den tredje prestandautmaningen är historikrensning, det vill säga när du kommer till den punkt där du inte behöver lagra några detaljerade mätvärden som har samlats in under 5 år (även månader eller två månader). Vissa nätverksnoder togs bort, eller vissa värdar, mätvärdena behövs inte längre eftersom de redan är föråldrade och inte längre samlade in. Allt detta måste rengöras så att din databas inte blir för stor. Generellt sett är rensningshistoriken oftast ett allvarligt test för lagringen - det har ofta en mycket stark inverkan på prestandan.
Hur löser man cachningsproblem?
Я сейчас буду говорить конкретно о «Заббиксе». В «Заббиксе» первый и второй вызовы решены с помощью кэширования.
Datainsamling och bearbetning – Vi använder RAM för att lagra all denna data. Dessa data kommer nu att diskuteras mer i detalj.
Även på databassidan finns en del cachning för huvudval - för grafer och annat.
Cachning på sidan av själva Zabbix-servern: vi har ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Vad det är?
ConfigurationCache är huvudcachen där vi lagrar mätvärden, värdar, dataobjekt, triggers; allt du behöver för att bearbeta förbearbetning, samla in data, från vilka värdar du ska samla in, med vilken frekvens. Allt detta lagras i ConfigurationCache för att inte gå till databasen och skapa onödiga frågor. Efter att servern startar uppdaterar vi denna cache (skapar den) och uppdaterar den regelbundet (beroende på konfigurationsinställningarna).
Cachar i Zabbix. Datainsamling
Här är diagrammet ganska stort:
De viktigaste i schemat är dessa samlare:
Det är själva monteringsprocesserna, olika ”pollare” som ansvarar för olika typer av sammanställningar. De samlar in data via icmp, ipmi och olika protokoll och överför allt till förbearbetning.
PreProcessing HistoryCache
Также, если у нас есть вычисляемые элементы данных (кто знаком с «Заббиксом» – знает), то есть вычисляемые, агрегационные элементы данных, – мы их забираем напрямую из ValueCache. О том, как он наполняется, я расскажу позже. Все эти сборщики используют ConfigurationCache для получения своих заданий и дальше передают на препроцессинг.
Förbearbetning använder också ConfigurationCache för att hämta förbearbetningssteg och bearbetar dessa data på olika sätt. Från och med version 4.2 har vi flyttat den till en proxy. Detta är mycket bekvämt, eftersom förbearbetningen i sig är en ganska svår operation. Och om du har en mycket stor Zabbix, med ett stort antal dataelement och en hög insamlingsfrekvens, så förenklar detta arbetet avsevärt.
Följaktligen, efter att vi har bearbetat denna data på något sätt med förbearbetning, sparar vi den i HistoryCache för att kunna bearbeta den vidare. Detta avslutar datainsamlingen. Vi går vidare till huvudprocessen.
Работа History syncer
Huvudprocessen i Zabbix (eftersom det är en monolitisk arkitektur) är History syncer. Detta är huvudprocessen som specifikt handlar om atombehandlingen av varje dataelement, det vill säga varje värde:
- värdet kommer (det tar det från HistoryCache);
- kontrollerar i Configuration syncer: om det finns några triggers för beräkning - beräknar dem;
om det finns - skapar händelser, skapar eskalering för att skapa en varning, om nödvändigt enligt konfigurationen; - registrerar triggers för efterföljande bearbetning, aggregering; om du aggregerar under den senaste timmen och så vidare, kommer detta värde att komma ihåg av ValueCache för att inte gå till historiktabellen; Således fylls ValueCache med nödvändig data som är nödvändig för att beräkna triggers, beräknade element, etc.;
- sedan skriver History syncer all data till databasen;
- databasen skriver dem till disken - det är här bearbetningsprocessen slutar.
Databas. Cachning
На стороне БД, когда вы хотите посмотреть графики либо какие-то отчёты по событиям, есть различные кэши. Но в рамках этого доклада я не буду о них рассказывать.
Для MySQL есть Innodb_buffer_pool, ещё куча различных кэшей, которые тоже можно настроить.
Но это – основные:
- shared_buffers;
- effective_cache_size;
- shared_pool.
För alla databaser sa jag att det finns vissa cacher som gör att du kan lagra i RAM den data som ofta behövs för frågor. De har sin egen teknik för detta.
Om databasprestanda
Följaktligen finns det en konkurrensutsatt miljö, det vill säga Zabbix-servern samlar in data och registrerar den. När den startas om läser den också från historiken för att fylla ValueCache och så vidare. Här kan du ha skript och rapporter som använder Zabbix API, som är byggt på ett webbgränssnitt. Zabbix API går in i databasen och tar emot nödvändig data för att få grafer, rapporter eller någon slags lista över händelser, senaste problem.
Также очень популярное решение для визуализации – это Grafana, которое используют наши пользователи. Умеет напрямую входить как через «Заббикс»-API, так и через БД. Оно тоже создаёт определённую конкуренцию для получения данных: нужна более тонкая, хорошая настройка БД, чтобы соответствовать быстрой выдаче результатов и тестирования.
Rensa historik. Zabbix har hushållerska
Det tredje samtalet som används i Zabbix är att rensa historik med hjälp av Housekeeper. Housekeeper följer alla inställningar, det vill säga våra dataelement indikerar hur länge som ska lagras (i dagar), hur länge trender ska lagras och dynamiken i förändringar.
Jag pratade inte om TrendCache, som vi beräknar i farten: data kommer, vi aggregerar det under en timme (detta är oftast siffror för den senaste timmen), mängden är genomsnittlig/minimum och vi registrerar den en gång i timmen i tabell över förändringarnas dynamik ("Trender") . "Hushållerska" startar och raderar data från databasen med vanliga val, vilket inte alltid är effektivt.
Как понять что это неэффективно? Вы можете на графиках производительности внутренних процессов видеть такую картину:
Din historiksynkronisering är ständigt upptagen (röd graf). Och den "röda" grafen som går överst. Detta är en "hushållerska" som startar och väntar på att databasen tar bort alla rader som den har angett.
Låt oss ta lite artikel-ID: du måste ta bort de senaste 5 tusen; givetvis genom index. Men vanligtvis är datasetet ganska stort - databasen läser fortfarande det från disken och lägger in det i cachen, och detta är en mycket dyr operation för databasen. Beroende på dess storlek kan detta leda till vissa prestandaproblem.
Отключить «Хаускипер» можно простым способом – у нас есть всем знакомый веб-интерфейс. Настройка в Administration general (настройки для «Хаускипера») мы отключаем внутренний housekeeping для внутренней истории и трендов. Соответственно, «Хаускипер» больше не управляет этим:
Vad kan du göra härnäst? Du stängde av den, dina grafer har planat ut... Vilka ytterligare problem kan uppstå i det här fallet? Vad kan hjälpa?
Partitionering (sektionering)
Обычно это настраивается на каждой реляционной базе данных, которые я перечислил, различным способом. На MySQL своя технология. Но в целом они очень похожи, если говорить о PostgreSQL 10 и MySQL. Конечно, там очень много внутренних различий, как это всё реализовано и как это всё влияет на производительность. Но в целом создание новой партиции часто тоже приводит к определённым проблемам.
Beroende på din inställning (hur mycket data du skapar på en dag) sätter de vanligtvis minimum - det här är 1 dag / batch och för "trender", förändringsdynamik - 1 månad / ny batch. Detta kan ändras om du har en mycket stor inställning.
Låt oss säga direkt om storleken på installationen: upp till 5 tusen nya värden per sekund (så kallade nvps) - detta kommer att betraktas som en liten "inställning". Genomsnitt - från 5 till 25 tusen värden per sekund. Allt som står ovan är redan stora och mycket stora installationer som kräver mycket noggrann konfiguration av databasen.
På mycket stora installationer kanske 1 dag inte är optimalt. Jag har personligen sett partitioner på MySQL på 40 gigabyte per dag (och det kan finnas fler). Detta är en mycket stor mängd data, vilket kan leda till vissa problem. Det måste minskas.
Varför behöver du partitionering?
Det som partitionering ger, tror jag att alla vet, är tabellpartitionering. Ofta är dessa separata filer på disk och span-förfrågningar. Den väljer en partition mer optimalt om den är en del av normal partitionering.
För Zabbix, i synnerhet, används det av intervall, efter intervall, det vill säga vi använder en tidsstämpel (ett vanligt tal, tid sedan epokens början). Du anger början på dagen/slutet på dagen, och detta är partitionen. Följaktligen, om du frågar efter data som är två dagar gammal, hämtas allt från databasen snabbare, eftersom du bara behöver ladda en fil i cachen och returnera den (istället för en stor tabell).
Många databaser gör också snabbare infogning (infogning i en underordnad tabell). Jag talar abstrakt för nu, men detta är också möjligt. Partitonering hjälper ofta.
Elasticsearch для NoSQL
Nyligen, i 3.4, implementerade vi en NoSQL-lösning. Lade till möjligheten att skriva i Elasticsearch. Du kan skriva vissa typer: du väljer - antingen skriv siffror eller några tecken; vi har strängtext, du kan skriva loggar till Elasticsearch... Följaktligen kommer webbgränssnittet också att komma åt Elasticsearch. Detta fungerar utmärkt i vissa fall, men för tillfället kan det användas.
TidsskalaDB. Hypertabeller
För 4.4.2 uppmärksammade vi en sak som TimescaleDB. Vad det är? Detta är en tillägg för PostgreSQL, det vill säga den har ett inbyggt PostgreSQL-gränssnitt. Dessutom låter detta tillägg dig arbeta mycket mer effektivt med tidsseriedata och ha automatisk partitionering. Vad det liknar:
Det här är hypertabell - det finns ett sådant koncept i Timescale. Det här är en hypertabell som du skapar, och den innehåller bitar. Chunks är partitioner, det här är underordnade tabeller, om jag inte har fel. Det är riktigt effektivt.
TimescaleDB och PostgreSQL
Som TimescaleDB-tillverkarna försäkrar använder de en mer korrekt algoritm för att bearbeta frågor, särskilt inlägg, vilket gör att de kan ha ungefär konstant prestanda med en ökande storlek på datasetinlägget. Det vill säga, efter 200 miljoner rader med Postgres börjar den vanliga sjunka väldigt mycket och tappar prestanda bokstavligen till noll, medan Timescale låter dig infoga inlägg så effektivt som möjligt med vilken mängd data som helst.
Hur installerar man TimescaleDB? Det är enkelt!
Det finns i dokumentationen, det beskrivs - du kan installera det från paket för alla... Det beror på de officiella Postgres-paketen. Kan kompileras manuellt. Det blev så att jag var tvungen att kompilera för databasen.
На «Заббикс» мы просто активируем Extention. Я думаю, что те, кто пользовался в «Постгресе» Extention… Вы просто активируете Extention, создаёте его для БД «Заббикс», которую используете.
Och det sista steget...
TidsskalaDB. Migrering av historiktabeller
Du måste skapa en hypertabell. Det finns en speciell funktion för detta – Skapa hypertabell. I den är den första parametern tabellen som behövs i den här databasen (för vilken du måste skapa en hypertabell).
Fältet för att skapa, och chunk_time_interval (detta är intervallet för chunks (partitioner som måste användas). 86 400 är en dag.
Параметр migrate_data: если вы вставляете в true, то это переносит все текущие данные в заранее созданные чанки.
Jag har själv använt migrate_data - det tar ganska lång tid, beroende på hur stor din databas är. Jag hade över en terabyte - det tog över en timme att skapa. I vissa fall, under testningen, tog jag bort historiska data för text (history_text) och string (history_str) för att inte överföra dem - de var inte riktigt intressanta för mig.
Och vi gör den sista uppdateringen i vår db_extention: vi installerar timescaledb så att databasen och i synnerhet vår Zabbix förstår att det finns db_extention. Han aktiverar den och använder rätt syntax och frågor till databasen, med hjälp av de "funktioner" som är nödvändiga för TimescaleDB.
Serverkonfiguration
Jag använde två servrar. Den första servern är en ganska liten virtuell maskin, 20 processorer, 16 gigabyte RAM. Jag konfigurerade Postgres 10.8 på den:
Операционная система была Debian, файловая система – xfs. Сделал минимальные настройки, чтобы использовать именно эту базу данных, за вычетом того, что будет использовать сам «Заббикс». На этой же машине стоял «Заббикс»-сервер, PostgreSQL и нагрузочные агенты.
Jag har använt 50 aktiva agenter som använder LoadableModule för att snabbt generera olika resultat. Det är de som genererade strängarna, siffrorna och så vidare. Jag fyllde databasen med mycket data. Inledningsvis innehöll konfigurationen 5 tusen dataelement per värd, och ungefär varje dataelement innehöll en trigger - för att detta skulle vara en riktig inställning. Ibland behöver du till och med mer än en trigger för att använda.
Интервал обновления, саму нагрузку я регулировал тем, что не только 50 агентов использовал (добавлял ещё), но и с помощью динамических элементов данных и снижал апдейт-интервал до 4 секунд.
Utvärderingsprov. PostgreSQL: 36 tusen NVP
Den första lanseringen, den första installationen jag hade var på ren PostreSQL 10 på denna hårdvara (35 tusen värden per sekund). I allmänhet, som du kan se på skärmen, tar det bråkdelar av en sekund att infoga data - allt är bra och snabbt, SSD-enheter (200 gigabyte). Det enda är att 20 GB fylls upp ganska snabbt.
Будет дальше достаточно много таких графиков. Это стандартный dashboard производительности «Заббикс»-сервера.
Den första grafen är antalet värden per sekund (blå, överst till vänster), 35 tusen värden i det här fallet. Detta (överst i mitten) är laddningen av byggprocesser, och detta (överst till höger) är laddningen av interna processer: historiksyncer och hushållerska, som här (längst ner i mitten) har varit igång ganska länge.
Den här grafen (längst ner i mitten) visar ValueCache-användning - hur många ValueCache-träffar för utlösare (flera tusen värden per sekund). En annan viktig graf är den fjärde (nederst till vänster), som visar användningen av HistoryCache, som jag pratade om, som är en buffert innan den infogas i databasen.
Utvärderingsprov. PostgreSQL: 50 tusen NVP
Därefter ökade jag belastningen till 50 tusen värden per sekund på samma hårdvara. När den laddades av hushållerskan, registrerades 10 tusen värden på 2-3 sekunder med beräkning. Vad som faktiskt visas i följande skärmdump:
"Hushållerska" börjar redan störa arbetet, men generellt sett är belastningen på historiesänkare fortfarande på nivån 60% (tredje grafen, uppe till höger). HistoryCache börjar redan fyllas aktivt medan Housekeeper körs (nedre till vänster). Den var ungefär en halv gigabyte, 20 % full.
Utvärderingsprov. PostgreSQL: 80 tusen NVP
Sedan ökade jag det till 80 tusen värden per sekund:
Это было примерно 400 тысяч элементов данных, 280 тысяч триггеров. Вставка, как видите, по загрузке хистори-синкеров (их было 30 штук) была уже достаточно высокая. Дальше я увеличивал различные параметры: хистори-синкеры, кэш… На данном железе загрузка хистори-синкеров начала увеличиваться до максимума, практически «в полку» – соответственно, HistoryCache пошёл в очень высокую загрузку:
Hela denna tid övervakade jag alla systemparametrar (hur processorn används, RAM) och upptäckte att diskutnyttjandet var maximalt - jag uppnådde den maximala kapaciteten för denna disk på den här hårdvaran, på den här virtuella maskinen. "Postgres" började dumpa data ganska aktivt med sådan intensitet, och disken hade inte längre tid att skriva, läsa ...
Jag tog en annan server som redan hade 48 processorer och 128 gigabyte RAM:
Jag "justerade" den också - installerade History syncer (60 stycken) och uppnådde acceptabel prestanda. I själva verket är vi inte "på hyllan", men detta är förmodligen gränsen för produktivitet, där det redan är nödvändigt att göra något åt det.
Utvärderingsprov. TidskalaDB: 80 tusen NVP
Min huvudsakliga uppgift var att använda TimescaleDB. Varje graf visar en dipp:
Эти провалы – как раз миграция данных. После этого в «Заббикс»-сервере профиль загрузки хистори-синкеров, как вы видите, очень сильно изменился. Он практически в 3 раза быстрее позволяет вставлять данные и использовать меньше HistoryCache – соответственно, у вас своевременно будут поставляться данные. Опять же, 80 тысяч значений в секунду – это достаточно высокий rate (конечно, не для «Яндекса»). В целом это достаточно большой setup, с одним сервером.
PostgreSQL prestandatest: 120 tusen NVP
Далее я увеличил значение количества элементов данных до полумиллиона и получил расчётное значение 125 тысяч в секунду:
И получил такие графики:
I princip är detta ett fungerande setup, det kan fungera ganska länge. Men eftersom jag bara hade en 1,5 terabyte disk använde jag den på ett par dagar. Det viktigaste är att det samtidigt skapades nya partitioner på TimescaleDB, och detta var helt obemärkt för prestanda, vilket inte kan sägas om MySQL.
Vanligtvis skapas partitioner på natten, eftersom detta i allmänhet blockerar insättning och arbete med tabeller och kan leda till försämring av tjänsten. I det här fallet är det inte så! Huvuduppgiften var att testa funktionerna i TimescaleDB. Resultatet blev följande siffra: 120 tusen värden per sekund.
Также есть в «комньюнити» примеры:
Человек тоже включил TimescaleDB и загрузка по использованию io.weight упала на процессоре; и использование элементов внутренних процессов тоже снизилось благодаря включению TimescaleDB. Причём это обычные блинные диски, то есть обычная виртуалка на обычных дисках (не SSD)!
För vissa små inställningar som begränsas av diskprestanda är TimescaleDB enligt min mening en mycket bra lösning. Det gör att du kan fortsätta arbeta innan du migrerar till snabbare hårdvara för databasen.
Приглашаю всех вас на наши мероприятия: Conference – в Москве, Summit – в Риге. Используйте наши каналы – «Телеграм», форум, IRC. Если у вас есть какие-то вопросы – приходите к нам на стойку, можем поговорить обо всём.
Publikens frågor
Fråga från publiken (nedan - A): - Om TimescaleDB är så lätt att konfigurera, och det ger en sådan prestandaboost, så kanske detta bör användas som en bästa praxis för att konfigurera Zabbix med Postgres? Och finns det några fallgropar och nackdelar med denna lösning, eller trots allt, om jag bestämde mig för att göra Zabbix för mig själv, kan jag enkelt ta Postgres, installera Timescale där direkt, använda den och inte tänka på några problem?
AG: – Ja, jag skulle säga att det här är en bra rekommendation: använd Postgres omedelbart med TimescaleDB-tillägget. Som jag redan sa, många bra recensioner, trots att denna "funktion" är experimentell. Men faktiskt tester visar att detta är en bra lösning (med TimescaleDB) och jag tror att den kommer att utvecklas! Vi övervakar hur denna förlängning utvecklas och kommer att göra ändringar vid behov.
Мы даже во время разработки опирались на одну их известную «фичу»: там можно было с чанками немного по-другому работать. Но потом они это в следующем релизе выпилили, и нам пришлось уже не опираться на этот код. Я бы рекомендовал использовать это решение на многих setup’ах. Если вы используете MySQL… Для средних setup’ов любое решение неплохо работает.
A: – På de sista graferna från samhället fanns det en graf med "Hushållerska":
Han fortsatte att arbeta. Vad gör Housekeeper med TimescaleDB?
AG: – Nu kan jag inte säga säkert – jag ska titta på koden och berätta mer detaljerat. Den använder TimescaleDB-frågor för att inte ta bort bitar, utan för att på något sätt aggregera dem. Jag är inte redo att svara på den här tekniska frågan ännu. Vi får veta mer i montern idag eller imorgon.
A: – Jag har en liknande fråga – om utförandet av raderingsoperationen i Timescale.
A (svar från publiken): – När du raderar data från en tabell, om du gör det via delete, måste du gå igenom tabellen - radera, rensa, markera allt för framtida vakuum. I Timescale, eftersom du har bitar, kan du släppa. Grovt sett säger du helt enkelt till filen som är i big data: "Radera!"
Timescale förstår helt enkelt att en sådan bit inte längre existerar. Och eftersom den är integrerad i frågeplaneraren använder den krokar för att fånga dina villkor i utvalda eller andra operationer och förstår omedelbart att den här biten inte längre existerar - "Jag kommer inte att gå dit längre!" (data ej tillgängliga). Det är allt! Det vill säga, en tabellskanning ersätts av en binär filradering, så det går snabbt.
A: – Vi har redan berört ämnet icke-SQL. Såvitt jag förstår behöver Zabbix egentligen inte ändra data, och allt detta är ungefär som en logg. Går det att använda specialiserade databaser som inte kan ändra sin data, men samtidigt spara, ackumulera och distribuera mycket snabbare - Clickhouse, till exempel, något Kafka-likt?.. Kafka är också en logg! Är det möjligt att på något sätt integrera dem?
AG: – Avlastning kan göras. Vi har en viss "funktion" sedan version 3.4: du kan skriva alla historiska filer, händelser, allt annat till filer; och sedan skicka den till vilken annan databas som helst med någon hanterare. Faktum är att många omarbetar och skriver direkt till databasen. I farten skriver historiesänkare allt detta till filer, roterar dessa filer och så vidare, och du kan överföra detta till Clickhouse. Jag kan inte säga något om planerna, men kanske kommer ytterligare stöd för NoSQL-lösningar (som Clickhouse) att fortsätta.
A: – Generellt sett visar det sig att man helt kan bli av med postgres?
AG: – Конечно, самая сложная часть в «Заббиксе» – это исторические таблицы, которые создают больше всего проблем, и события. В этом случае, если вы не будете долго хранить события и будете хранить историю с трендами в каком-то другом быстром хранилище, то в целом никаких проблем, думаю, не будет.
A: – Kan du uppskatta hur mycket snabbare allt kommer att fungera om du till exempel byter till Clickhouse?
AG: – Jag har inte testat det. Jag tror att åtminstone samma siffror kan uppnås helt enkelt, med tanke på att Clickhouse har sitt eget gränssnitt, men jag kan inte säga säkert. Det är bättre att testa. Allt beror på konfigurationen: hur många värdar du har och så vidare. Att infoga är en sak, men du måste också hämta denna data - Grafana eller något annat.
A: – Så vi talar om en jämlik kamp, och inte om den stora fördelen med dessa snabba databaser?
AG: – Думаю, когда интегрируем, будут более точные тесты.
A: – А куда делся старый добрый RRD? Что заставило перейти на базы данных SQL? Изначально же на RRD все метрики собирались.
AG: – Zabbix hade RRD, kanske i en väldigt gammal version. Det har alltid funnits SQL-databaser – ett klassiskt tillvägagångssätt. Det klassiska tillvägagångssättet är MySQL, PostgreSQL (de har funnits väldigt länge). Vi använde nästan aldrig ett gemensamt gränssnitt för SQL- och RRD-databaser.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com