Accounting for network traffic in the cloud
The last, final article in the series on how cloud resources are counted. Previous: processor , memory , disks .
Accounting for Internet traffic is probably the easiest topic of all. How many bytes to the network interface came - such and incoming traffic. How many bytes are gone - so outgoing.
Unusual, probably, is only that traffic is taken into account not at the third (network) level, but at the second (channel) level. The choice of the level does not carry any sacred meaning, just in the technology used, the most accurate and simple accounting is done precisely by the number of bytes transmitted at the channel level. From a technical point of view, this is the accounting of transmitted bytes through the VIF (virtual network interface of the machine). The only unpleasant side effect is that any service traffic, such as outgoing broadcasts, ARP, etc. also taken into account. But, taking into account the cost of traffic (10 -6 rubles per kilobyte), I can hardly imagine how to wrap at least a penny with official traffic.
A positive aspect (for us, and in some sense for the client) is that if a client picks up a heavy application at the second level (l2tp, PPPoE, ATAoE), then it will be considered the same as any other L3 protocol, without the need to “fool” on the client and force him to stop using the inconvenient for accounting protocol that does not fit into the “read by IP” model.
Since there is nothing trivial about how traffic is considered, I cannot tell you, I will talk about a more interesting question - what is better: traffic or a lane?
')
One of the common misconceptions in estimating the cost of traffic is to take a band (for example, 10 megabits) and multiply it by 720 * 3600, that is, calculate how much such a band will give a maximum.
However, in comparison with other resources, it is the network that shows the most uneven consumption (huge peaks with huge failures). A network loaded at 100% - will not give the desired quality of service due to delays.
For many cars, the difference between night and day traffic can reach a ratio of 20: 1, or even 30: 1. Prediction of the band in this case is an eternal struggle of greed with justice - if a site lays 10 minutes a day due to a sharp peak of load - will it buy more lanes or not?
In the cloud, each host (the server that makes up the cloud) is connected at a speed of 1 Gb / s, and the channels to the set of uplinks (not counting peering) are more than 10 Gb / s. And, taking into account our equipment, there are no special problems to expand it to the desired value (as well as bring 10G to each host).
Well, the last question that arises in connection with traffic. Is it possible to "smaller"? If you want to "better slowed down, but did not consider much?". Yes you can. In linux, it’s quite simple to limit the speed of incoming / outgoing connections. This can be done by the user of the virtual machine. Why aren't we? Because sheyper - separate equipment that costs money. If it costs money and is not needed by most customers, then why should they pay for it with more expensive traffic (and we would have made it more expensive if the cost price was higher) for several customers?
At the beginning of the article there is a real daily schedule of a very busy site (I think you can guess where the night is and where the day is).
But another chart is a small homepage of a small student site:
(Note about charts: rx / tx is considered from the point of view of the cloud, that is, rx for the cloud is outgoing traffic for the client, and vice versa)
Accounting for Internet traffic is probably the easiest topic of all. How many bytes to the network interface came - such and incoming traffic. How many bytes are gone - so outgoing.
Unusual, probably, is only that traffic is taken into account not at the third (network) level, but at the second (channel) level. The choice of the level does not carry any sacred meaning, just in the technology used, the most accurate and simple accounting is done precisely by the number of bytes transmitted at the channel level. From a technical point of view, this is the accounting of transmitted bytes through the VIF (virtual network interface of the machine). The only unpleasant side effect is that any service traffic, such as outgoing broadcasts, ARP, etc. also taken into account. But, taking into account the cost of traffic (10 -6 rubles per kilobyte), I can hardly imagine how to wrap at least a penny with official traffic.
A positive aspect (for us, and in some sense for the client) is that if a client picks up a heavy application at the second level (l2tp, PPPoE, ATAoE), then it will be considered the same as any other L3 protocol, without the need to “fool” on the client and force him to stop using the inconvenient for accounting protocol that does not fit into the “read by IP” model.
Since there is nothing trivial about how traffic is considered, I cannot tell you, I will talk about a more interesting question - what is better: traffic or a lane?
')
One of the common misconceptions in estimating the cost of traffic is to take a band (for example, 10 megabits) and multiply it by 720 * 3600, that is, calculate how much such a band will give a maximum.
However, in comparison with other resources, it is the network that shows the most uneven consumption (huge peaks with huge failures). A network loaded at 100% - will not give the desired quality of service due to delays.
For many cars, the difference between night and day traffic can reach a ratio of 20: 1, or even 30: 1. Prediction of the band in this case is an eternal struggle of greed with justice - if a site lays 10 minutes a day due to a sharp peak of load - will it buy more lanes or not?
In the cloud, each host (the server that makes up the cloud) is connected at a speed of 1 Gb / s, and the channels to the set of uplinks (not counting peering) are more than 10 Gb / s. And, taking into account our equipment, there are no special problems to expand it to the desired value (as well as bring 10G to each host).
Well, the last question that arises in connection with traffic. Is it possible to "smaller"? If you want to "better slowed down, but did not consider much?". Yes you can. In linux, it’s quite simple to limit the speed of incoming / outgoing connections. This can be done by the user of the virtual machine. Why aren't we? Because sheyper - separate equipment that costs money. If it costs money and is not needed by most customers, then why should they pay for it with more expensive traffic (and we would have made it more expensive if the cost price was higher) for several customers?
At the beginning of the article there is a real daily schedule of a very busy site (I think you can guess where the night is and where the day is).
But another chart is a small homepage of a small student site:
(Note about charts: rx / tx is considered from the point of view of the cloud, that is, rx for the cloud is outgoing traffic for the client, and vice versa)
Source: https://habr.com/ru/post/112043/
All Articles