Selles artiklisarjas tahame käsitleda küsimusi, mis tekivad inimestel töötades veebihostinguteenuse pakkujate ja pühendatud serveritega. Enamiku aruteludest oleme pidanud ingliskeelsetel foorumitel, püüdes kasutajatele esmajoones anda nõu, mitte reklaamida ennast, pakkudes võimalikult üksikasjalikku ja erapooletut vastust, sest meie kogemus valdkonnas ulatub juba üle 14 aasta, sadu edukaid lahendusi ja tuhandeid rahulolevaid kliente. Siiski ei tohi meie vastuseid käsitleda kui ainsaid õigeid vastuseid, nad võivad sisaldada ebatäpsusi ja isegi vigu, keegi ei ole ideaalne. Oleme tänulikud, kui täiendate või parandate neid kommentaarides.
Miks on serveri hind, millel on 100 TB liikluspiirang ja 1 Gbit/s kanal, palju madalam kui serveri hind, millel on 1 Gbit/s kanal ilma liikluseta? Sest kui rentida 2-3 serverit 1 Gbit/s kanali ja 100 TB piiranguga, saab kasutada täpselt sama palju kui serveri puhul, millel on 1 Gbps Unmetered, või isegi rohkem kanalit tipphetkedel, samas kui pakkuja tegelikult pakub rohkem riistvara, rohkem ühendusi ja madalamat hinda?
Asi on selles, et pakkujad, pakkudes servereid suhteliselt suure liikluspiiranguga või isegi „piiramatu“ liiklusega väikese raha eest, võtavad arvesse oma klientide keskmisi tarbimismustreid. Selgus, et enamik kliente, kes ostavad selliseid kanaleid, ei kasuta neile antud ühenduvust täielikult. Just seetõttu on võimalik teha selliseid pakkumisi.
100 TB liiklust — üsna suur piirang. See on rohkem kui 100 Mbps Unmetered. Kui meil on 100 Mbit/s kanal ilma arvestuseta, saame maksimaalselt edastada 100 (kiirus megabittides) * 86400 (sekundid päevas) * 30 (päeva) / 8 (bitti baitides) / 1000 (megabeitides gigabaitides, kui arvestame 1000, mitte 1024, 1024 on bit kibibitides) = 32 400 GB kuus igas suunas, kui kanal on pidevalt 100%-liselt kasutusel. Kuid nagu me teame, ei tarbi serverid liiklust pidevalt ja sageli võivad päevased tarbimiskõverad olla sellised:
Mõnel võivad tipud saavutada maksimumi läbilaskevõimes ja nõuda ausat 1 Gbit/s nendel hetkedel. Kuid kuu üldine liikluse piirang ei pruugi peaaegu ületatud olla:
Sellised kliendid ei ole pakkujate jaoks eriti kasumlikud, seetõttu püüab pakkuja neid viia Unmetered'i, kuna kui ta pakub teenuseid klientidele ühest piirkonnast, on tõenäoline, et tarbimise tipud kattuvad ja see 'aus' gigabit, mida pakkuja suudab müüa, ei pruugi ulatuda üle 1,2 kliendi. Kui aga pakkujal on kliente erinevatest piirkondadest, on täiesti võimalik, et kanal müüakse kahele või enamale tellijale korraga, kuna tarbimise tipud erinevatel auditooriumidel on ajaliselt erinevad. Tegelikult ei tarbi aga sugugi iga klient oma 100 TB limiiti, seetõttu on serverite pakkumine 100 TB liiklusega äärmiselt kasulik.
Veelgi enam, kui ühendame riiulitega 10 gigabiti kanaleid, suudame väga tõhusalt jaotada liiklust kõigi vahel. Me suudame jagada 10 Gbit/s kanali keskmiselt 5 riiuli vahel, millel on serverid 100 TB limiidiga. See on umbes 150 serverit. Kuna ühe 47-rakendusüksusega riiuli mahutab kas 41 ühesuunalist serverit või 21 kahe suunaga serverit.
Kokkuvõttes on kanali kogutarbimine järgmine:
Kui aga keelduda teenindamast tellijaid, kes genereerivad palju liiklust (peamine panus kanali koormusse on vähem kui 10 serverit 150-st, mis on sellel porti), siis on võimalik serverite arvu suurendada 300-ni ja rohkem. Ja kõik on rahul ning kõigile jätkub liiklust.
Siiski on ka teisi viise, kuidas säästa ja mitte häirida tellijaid — ühendada odavam transiitülesanne või suunata liiklus vahetuspunkti või peeringusse tasuta, kui olete suur liikluse genereerija.
Just this allows us to maintain low prices, without denying subscribers service, paying transit providers €1500-6000 for every 10G depending on how good the transit provider is, and selling connectivity at a loss with a certain oversell ratio, where each subscriber has their ordered fair channel, without interfering with each other.
It becomes immediately clear why the price for 1Gbps Unmetered is significantly higher, because if with 100 terabyte servers, not everyone consumes their limit, a customer who orders 1Gbps Unmetered will clearly use a large portion of the channel. Although we have seen the above exception and an example of how to generate almost 1 Gbit/s traffic in peaks while still being within 100 terabyte limits, this is an exception, not a typical pattern.
My administrator installed the vnstatd program on the server, traffic is monitored from the interface every 5 minutes. Does it take everything into account? It shows that 87 TB has been used, while the provider says that 96 TB has been used and the traffic is almost over. I trust my sysadmin, he is an excellent specialist. And if he says the provider is overestimating consumption, then it is indeed so. Moreover, the fact that they started playing with values, giving different values for traffic for the same period during the discussion, also indicates this. We are still waiting for an answer to the question "how is that possible?"
The thing is that some traffic accounting programs track data in TiB instead of TB. In tebibytes, not terabytes. That is, accounting is done using a binary system instead of a decimal system, based on the fact that in a kilobyte, or more accurately, in a kibibyte, there are 1024 bytes, not 1000.
Oluline on märkida, et marketingi eesmärkidel ei kasutata seda erinevust, ISO (Rahvusvaheline Standardimisorganisatsioon) on juba ammu sisse seadnud eesliite «bi» binaarsete baitide jaoks, st kibibaitide, mibibaitide, gibibaitide ja tibibaitide jaoks. Siiski on turundus toimunud ning kui salvestusseadmete tootjad suudavad kümnendike baitide toel näidata väiksemaid salvestusmahte, siis andmete mõõtmise ja jälgimise puhul on olukord vastupidine. Juhul, kui hostimisteenuse pakkuja pakub 100 TB liiklust, annab ta seda vähem, kui see võiks tegelikult olla, kui seda arvestada binaarsüsteemi järgi.
Tundub, et erinevus ei ole suur, vaid ainult 24 baiti 1000 kohta, viga on vaid 2,4%, kuid miks tekib nii suur erinevus, umbes 10%? Kas tõesti pole mingit liiklust arvesse võetud?
Asi on selles, et ei tohi unustada, et “viga” koguneb, nimelt:
1024 baiti kibibaitis (kui rääkida ISO standardite kohaselt), mibibaitis on juba 1024*1024 = 1 048 576 baiti, gibibaitis — 1024*1024*1024 = 1 073 741 824, ja tibibaitis — 1024*1024*1024*1024 = 1 099 511 627 776.
Üllatav pöörde? Jah?
Liiklust teraaibaitides mõõtes on erinevus mõõtühikute vahel täpselt 10%!
Veelgi enam, erinevus andmetes, mis võetakse lüliti pordist ja serveri pordist, võib olla põhjustatud DDOS-rünnakust, mis ei jõua kliendini ja võib olla kõrvaldatud „marsruutimise“ tasandil, kuid selle käigus toimub siiski liikluse tarbimine.
Samuti tuleb arvestada, et mõnikord arvestab programm liiklust mitte kõigilt portidelt ja teatud liiklus võib „libiseda“ jälgimisest mööda.
Ja tuleb ka märkida, et kui pakutakse piiratud liiklust, arvestatakse sageli kumulatiivset sissetulevat + väljuvat liiklust, ja kui teil on näiteks VPN-teenus, on suhe 1:1 ning teie kliendid saavad kokku kulutada mitte rohkem kui 50 TB liiklust, kui piirang on 100.
Jätkub…
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. , ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).
Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest
Allikas: habr.com
