Не так давно у нас случился интересный инцидент, который действительно требует отдельного освещения и поможет избежать возможных недоразумений в будущем. Случай в своем роде уникальный, ведь клиентка, с которой мы успешно сотрудничали практически со дня своего официального открытия (2009-го года, 7 лет работы!), обвинила нас в мошенничестве и весьма странном учете трафика.

И тут причина была не только в недостаточной осведомленности клиентки, но и администраторов, которые банально не заметили разницы, либо также не осознавали её. Именно по этой причине мы решили разобрать данный случай.

Предыстория

Елена пришла к нам в 2009-м году, не обладая средствами на собственный выделенный сервер, зато обладая довольно интересным проектом, мы решили дать шанс — и отдали значительную часть ресурсов собственного выделенного сервера, практически по себестоимости. Со временем проект вырос и начал генерировать десятки и даже сотни мегабит трафика, потребовал нескольких выделенных серверов. А когда трафик стал равным 2 Гбит / c и потребовался третий, стало очевидно, что лучшего решения, чем сервер с 10Gbps Unmetered подключением, для Елены не существует. Ведь это было выгодно, как по цене, так и по оптимизации программного обеспечения, хотя и обеспечивало меньшую отказоустойчивость, в сравнении со случаем использованием нескольких серверов.

Какое-то время проект работал и только набирал обороты, однако ситуация изменилась, курс доллара вырос, цены на рекламу упали, онлайн-стримминг столкнулся со сложностями со стороны поборников авторского права, популярность проекта снижалась, как и потребности в серверном обеспечении. Проект перешел в начале на сервер с подключением 2x1 Гбит / с, затем на 1 Гбит / с, а затем стало очевидно, что более выгодно арендовать несколько акционных серверов с 100 ТБ трафика и подключением 1 Гбит / с, нежели один сервер с гигабитным подключением и отсутствием учета трафика.

К примеру, мы предлагаем выделенный сервер в Нидерландах http://www.ua-hosting.company/servers с ограничением трафика в 100ТБ и гигабитным подключением:

2 x Intel Quad Core Xeon E5504 / 32GB DDR3 / 4 x 240GB SSD / 1Gbps 100TB — $139 / месяц,

а те, кому нужно больше дискового пространства и не нужны SSD — могут выбрать подобную конфигурацию у нас с процессором Е5620 и 6 накопителями по 2 ТБ по примерно той же цене.

Это, как правило, в 3-4 раза дешевле, нежели 1 подобный сервер с подключением 1 Гбит / с и трафиком без учета, и в то же время является более выгодным предложение, так как в результате:

— абонент получает более отказоустойчивую среду, так как в случае выхода из строя аппаратной части, недоступной становится только часть вычислительных мощностей и полосы;
— большее количество CPU, RAM, SSD или HDD накопителей (в 3-4 раза);
— больше трафика возможно отдать.

По последнему пункту парадокс, но это так, 3 сервера с подключением 1 Гбит / с и лимитом трафика в 100 ТБ, позволят отдать больше трафика, нежели один сервер с гигабитным подключением без учета трафика (почти во всех случаях), так как по сути есть доступ к каналу в 3 Гбит / с. С подключением в 1 Гбит / с генерировать 300 ТБ трафика вряд ли удастся, так как суточная кривая потребления неравномерная, ночью качают гораздо меньше, нежели днем, а 300 ТБ достижимы только разве что при почти что 100% загрузке канала 100% времени на протяжении месяца, так что эта цифра реальна разве что в случаях:

— когда наблюдается сатурация канала (пользователи могут потребить больше трафика, но не позволяет канал и в результате полоса распределяется между пользователями, в результате чего каждый из пользователей уже не может получить максимальную скорость, а в некоторых случаях, к примеру, в случае сатурации канала с большим % потерь пакетов, даже необходимую, в результате чего буферизация видео тупит);

— в случае большого % входящего трафика (проксирование, обработка входящих запросов и т.п.).

Рекомендации

Разные провайдеры считают трафик по разному. Кто-то снимает данные с порта свитча, а кто-то — лишь на бордере, корневом пограничном маршрутизаторе дата-центра. В результате чего не весь трафик может учитываться, либо может учитываться даже трафик, который физически не дошел до сервера, в случае использования того же netflow (тот же DDOS по UDP, который был порезан на бордере). У кого-то данная статистика обновляется онлайн раз в несколько минут, а у кого-то — раз в сутки. К примеру, в случае больших объемов трафика на пограничных маршрутизаторах или в целом большого объема данных для анализа, в сотни и даже тысячи гигабит, бывает довольно затруднительно и затратно обновлять статистику чаще, чем раз в сутки, в результате чего полная статистика доступна, но с задержкой.

По этой причине мы в любых случаях рекомендуем наших клиентам оставлять 5-15% от неиспользованного объема трафика в резерве, в зависимости от интенсивности суточного потребления и времени, необходимого на поставку и настройку дополнительного сервера, для перераспределения нагрузки на него.

Также резерв будет необходим и на случай, если одна из нод выйдет из строя и нагрузка обрушится на оставшиеся ноды.

В результате такого резервирования можно сэкономить немало нервов, избежать проблем с перерасходом, в том числе по причине задержки обновления статистики, доставки оборудования, спокойно дождаться поставки нового сервера и провести его настройку, а также спокойно пережить худший сценарий — случай выхода из строя ноды.

Не экономьте эти 5-15% бюджета, они не стоят того.

В нашем случае ситуация была более интересная, такая, которая не описывается ничем из того, что указано выше. Хотя она имела место быть только по той причине, что клиентка не оставляла достаточный резерв, ведь был бы резерв — этого и обсуждения и не возникло бы, расхождений в данных по трафику и не заметили бы, хотя их на самом деле и не было…

Что произошло

Клиентка хотела использовать трафик почти на 100%, несмотря на то, что 3 сервера было в работе, была предоставлена хорошая скидка, но 4-й сервер, еще за 100 долларов, бюджет, вероятно, никак не позволял арендовать. Однако — это выбор клиента, он имеет на него право. Тем более, что мы всегда идем на уступки нашим абонентам и когда идет речь о добавлении нового сервера, в случае проблем с оплатой, даем возможность воспользоваться сервером на срок до месяца практически бесплатно, так как у нас зачастую доступно оборудование в резерве, а когда недоступно — заказываем под клиента и предоставляем нужную отсрочку.

Тем не менее, Елена решила, что влезет в лимит 100 ТБ, несмотря на то, что ее статистика уже говорила об использовании почти 84, а до конца месяца еще оставалось 5 дней и банальный расчет показывал, что трафика должно не хватить, однако, она надеялась, что нагрузка была связана с праздниками и трафика все же хватит.

К удивлению Елены, трафик почти закончился на следующий день, достигнув значения в 87 TiB (по ее данным) и в 96 ТБ по нашим, о чем мы проинформировали Елену, что хорошо было бы добавить сервер.

У Елены, возникли логичные вопросы, почему наше значение больше, как так?

Она обратилась, как в нашу поддержку, так и в поддержку дата-центра, так как статистика все же предоставляется дата-центром, с вопросом и обвинениями, что мол, как так, что у нас неправильно считают трафик.

Инженеры долго молчали, обновляли данные по статистике, но никаких расхождений в учете не выявили и не смогли внятно ответить на этот вопрос клиентке сразу. А это были, к слову, выходные, когда люди из отдела NOC доступны разве что по телефону или очень в критических случаях, потому подробный анализ ситуации пообещали дать не ранее понедельника.

Наш же технический отдел, видимо сильно ушел в работу, либо банально не заметил маленькой детали в сообщении от администратора Елены, отображающего данные с vnstat, которой пользовался её администратор для сбора статистики и который также полагал, что проблема у нас, либо на стороне дата-центра, из-за которой он видит не весь трафик, и послал через нас в ЦОД следующий запрос, в котором изложил, что есть расхождение в 10% с его данными и в конце даже указал возможные, по его мнению, причины:

eth2 / monthly

month rx | tx | total | avg. rate
------------------------+-------------+-------------+---------------
Jul '15 459.59 GiB | 16.68 TiB | 17.13 TiB | 54.93 Mbit/s
Aug '15 1.05 TiB | 47.04 TiB | 48.10 TiB | 154.25 Mbit/s
Sep '15 847.71 GiB | 37.69 TiB | 38.52 TiB | 127.66 Mbit/s
Oct '15 865.86 GiB | 35.36 TiB | 36.21 TiB | 116.13 Mbit/s
Nov '15 638.09 GiB | 28.18 TiB | 28.80 TiB | 95.45 Mbit/s
Dec '15 483.77 GiB | 21.62 TiB | 22.09 TiB | 70.84 Mbit/s
Jan '16 840.79 GiB | 36.21 TiB | 37.04 TiB | 118.78 Mbit/s
Feb '16 2.20 TiB | 83.32 TiB | 85.52 TiB | 293.19 Mbit/s
Mar '16 1.90 TiB | 84.92 TiB | 86.82 TiB | 304.64 Mbit/s
------------------------+-------------+-------------+---------------
estimated 2.08 TiB | 92.91 TiB | 94.99 TiB |

Can you please provide traffic information from your switch for 1 day / 1 month / for last 7 days and etc?

Seem's our server have own VLAN and i don't see a lot other traffic on server interface via tcpdump (multicast for example).

Thank you.

Елена, не дождавшись ответа инженеров дата-центра, несмотря на 7 лет успешного сотрудничества, решила опубликовать в сети Интеренет отзыв, что мы по странному считаем трафик и даже ведем нечестный учет, причем публично, на форумах, “Если брать у уа хостинг сервер с лимитированным трафиком, то будете иметь много сюпризов. И окажется, что трафик они считают как-то по особому и у них всегда на 10% больше. Причем данными манипулируют как считают нужными”.

Там же сообщила о намерении отказаться от наших услуг.

Информация дошла до меня и я попробовал разобраться, в чем же дело. Сразу бросилось в глаза то, что в статистике указаны все же TiB, а не TB. Тебибайты, а не терабайты. То есть учет ведется по двоичной системе, а не десятичной, из расчета того, что в килобайте, а точнее в кибибайте — 1024 байт, а не 1000.

Стоит отметить, что для того, чтобы это различие не использовалось в маркетинговых целях, ISO (International Standartization Organisation) уже давно ввела приставки “би” для двоичных байт, то есть кибибайты, мебибайты, гибибайты, тебибайты. Вот только, маркетинг все же состоялся, и если производители накопителей за счет десятичных байт — указывают меньшие объемы емкости накопителей, то при измерении и учете трафика — ситуация сработала с точностью до наоборот. Дата Центр, предоставляя трафика 100 ТБ, предоставляет его меньше, чем его может быть на самом деле.

Казалось бы, различие невелико, всего лишь 24 байт на 1000, погрешность от этого — всего лишь 2,4%, но почему у клиентки столь большая разница, на уровне 10%? Может действительно не учли какой-то трафик?

И тут я уже допустил ошибку, забыв о том, что “погрешность” нарастает, а именно:

1024 байт в кибибайте (если говорить в соответствии со стандартами ISO), в мебибайте уже 1024*1024 = 1 048 576 байт, в гибибайте — 1024*1024*1024 = 1 073 741 824, а в тебибайте — 1024*1024*1024*1024 = 1 099 511 627 776.

Неожиданный поворот? Да?

Получается, что на больших объемах трафика, “погрешность” доходит как раз до 10%, что и наблюдается, у нашей клиентки.

Инцидент был исчерпан и клиентка, после предоставления этой информации и подробных объяснений, решила все же продолжить с нами работу.

Выводы.

— игнорировать эффект различия между десятичными и двоичными байтами при большом трафике уже нельзя, для наглядности различия в процентах — приведем скрин из Wikipedia:


— дата-центры нашли легальный способ экономить трафик, потому, даже предоставляя пользователю небольшие объемы трафика, очень часто любят указывать его именно в терабайтах (экономия при этом максимальна и на 3% больше, нежели при указании в гигабайтах), таким образом экономия составляет до 5-10% трафика дополнительно, что, при общем потреблении, скажем в 2,4 терабита / с, обеспечит до четверти терабита экономии полосы! А это, если брать случай с каналом от магистрального оператора первого уровня — 600*256 = $153 600 в месяц или свыше миллиона долларов в год.

Именно по причине того, что учитывать различие между десятичными и двоичными байтами крайне важно, особенно в эпоху видео-стримминга и постоянного роста потребления трафика, мы решили акцентировать внимание на этом вопросе на Хабре, возможно многим из Вас это различие было известно, но наверняка далеко не все задумывались, насколько важным оно может быть и как эти знания можно эффективно использовать в том числе в маркетинговых целях.

Нам очень интересно, была ли эта статья полезна, потому мы хотим провести небольшой опрос. Отвечайте пожалуйста, только честно.