Мифы про хостинг. Миф первый. Чем меньше пинг, тем лучше хостинг
Опубликовано 25 Ноябрь 2007 в: 4 хостинг мифа
Часто при выборе хостинга владельцы сайтов интересуются «пингом» до сервера, на котором собираются разместить свой проект. Бытует мнение, что от этого параметра напрямую зависит время загрузки страниц. Соответственно, пинг считается едва ли не самым важным при выборе хостинг-провайдера. Это распространенное заблуждение.Диагностическая утилита ping была написана Майком Муусом в декабре 1983 г. (еще до изобретения протокола HTTP) как инструмент для выявления проблемных мест в IP-сетях. За 23 года эта программа практически не изменилась: она по-прежнему использует для замера скорости прохождения пакетов в сети сигнальный протокол ICMP. Протокол ICMP предназначен для передачи по сети сигнальных сообщений, в основном, сообщений об ошибках.
В наши дни программа ping входит в комплект большинства операционных систем. Маленькая утилита стала широко известна и теперь повсеместно используется не по назначению. Например, ее используют для оценки скорости доступа к серверу. Но ведь программа предназначена вовсе не для этого. Давайте, разберемся, что именно показывает ping.
Программа показывает суммарное время, которое затрачивает сигнальный пакет ICMP для того, чтобы достигнуть точки назначения и вернуться обратно в виде отклика. Казалось бы, пинг указывает на качество связи. Да, но с одной очень важной оговоркой. Нужно учитывать, что информация с веб-сервера загружается в браузер пользователя по HTTP, с использованием протокола TCP, а вовсе не сигнального протокола ICMP. Протокол TCP — это рабочий протокол, который реально используется различными приложениями. Именно время отклика по HTTP является действительно важной характеристикой, позволяющей судить о скорости работы сервера. Измерение сигнального ICMP-пинга в этом смысле совершенно не показательно. Дело в том, что пинг по HTTP и пинг по ICMP — это абсолютно разные показатели.
Рассмотрим реальные примеры, в которых для оценки ICMP-пинга использовалась обычная программа linux ping, а HTTP-ответы измерялись с помощью утилиты httping. Утилита httping отличается тем, что посылает не сигнальные, а реальные запросы HEAD, и уже по ним замеряет время отклика от сервера (страницы целиком не скачиваются). Это более объективный параметр, который позволяет реально оценить доступность сайта.
Измерения производились 3 ноября 2006 г. в 13:00 с сервера, расположенного в Минске на незагруженном ADSL-канале емкостью 1 мегабит. Мы запустили тест для двух сайтов: Google.de и Yahoo.de. Для каждого из них сначала указывается результат работы обычной утилиты ping, а затем — результат работы утилиты httping.
GOOGLE.DE
root@debian [~] # ping google.de
PING google.de (72.14.221.104): 56 data bytes
64 bytes from 72.14.221.104: icmp_seq=0 ttl=243 time=21.993 ms
64 bytes from 72.14.221.104: icmp_seq=1 ttl=243 time=21.960 ms
64 bytes from 72.14.221.104: icmp_seq=2 ttl=243 time=21.997 ms
64 bytes from 72.14.221.104: icmp_seq=3 ttl=243 time=22.603 ms
— google.de ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.960/22.138/22.603/0.269 ms
root@debian [~] # httping -g http://google.de
PING google.de:80 (http://google.de):
connected to google.de:80, seq=0 time=111.20 ms
connected to google.de:80, seq=1 time=103.57 ms
connected to google.de:80, seq=2 time=157.58 ms
connected to google.de:80, seq=3 time=134.55 ms
— http://google.de ping statistics —
4 connects, 4 ok, 0.00% failed
round-trip min/avg/max = 103.6/126.7/157.6 ms
YAHOO.DE
root@debian [~] # ping yahoo.de
PING yahoo.de (217.12.3.11): 56 data bytes
64 bytes from 217.12.3.11: icmp_seq=0 ttl=241 time=30.079 ms
64 bytes from 217.12.3.11: icmp_seq=1 ttl=241 time=32.061 ms
64 bytes from 217.12.3.11: icmp_seq=2 ttl=241 time=31.993 ms
64 bytes from 217.12.3.11: icmp_seq=3 ttl=241 time=42.888 ms
— yahoo.de ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 30.079/34.255/42.888/5.047 ms
root@debian [~] # httping -g http://yahoo.de
PING yahoo.de:80 (http://yahoo.de):
connected to yahoo.de:80, seq=0 time=78.78 ms
connected to yahoo.de:80, seq=1 time=76.46 ms
connected to yahoo.de:80, seq=2 time=94.78 ms
connected to yahoo.de:80, seq=3 time=75.81 ms
— http://yahoo.de ping statistics —
4 connects, 4 ok, 0.00% failed
round-trip min/avg/max = 75.8/81.5/94.8 ms
Как видно из примеров, результаты достаточно показательны сайт Yahoo.de с большим в 1,5 раза ICMP-пингом показал меньшее в 1,5 раза время HTTP-ответа, то есть с меньшей задержкой выдавал веб-страницы.
Такая ситуация встречается повсеместно. Чем она объясняется? Причин много:
* далекие от оптимальных настройки HTTP-сервера и сетевого оборудования;
* ассиметрия каналов oт сервера и к серверу;
* перегруженность каналов, на которых находится исследуемый сервер;
* перегруженность сервера, на котором находится сайт;
* другие факторы.
Миф о том, что пинг до сервера является показателем эффективности хостинга на этом сервере, не имеет под собой абсолютно никаких оснований. ICMP-пинг никак не может дать реальное представление о работе будущего сайта. Для объективной оценки нужно учесть целый ряд других параметров, в том числе не зависящих от хостеров и дата-центров, как, например, дневные пики нагрузки на сети промежуточных провайдеров. Некоторые из этих параметров учитывает утилита httping, которую можно рекомендовать в качестве более объективной альтернативы ping.
Кроме httping, для дополнительной оценки эффективности работы серверов Apache по протоколу HTTP предназначена специальная утилита ab. Она показывает, в том числе, сколько одновременных запросов способен выдержать сервер. Существуют и другие специальные инструменты для оценки работы веб-серверов. Например, бесплатная тестовая служба NetMechanic измеряет скорость загрузки информации с сервера каждые 15 минут в течение восьми часов, а затем присылает по почте подробный отчет. Другой сервис Speed-Meter тщательно тестирует скорость работы веб-сервера, обращаясь к нему из разных уголков мира. Это уже ближе к реальной оценке качества хостинга, чем глупое баловство с пингом по сигнальному протоколу.
Анатолий Ализар
Материал подготовлен при содействии хостинг-провайдера “Экстмедиа”.
Миф второй. Стомегабитный канал
Опубликовано 25 Ноябрь 2007 в: 4 хостинг мифа
Люди, которые выбирают хостинг, часто становятся жертвами маркетинговых уловок. Например, многие доверчивые пользователи склонны думать, что сервер, подключенный к 100-мегабитному каналу в США, будет работать быстрее, чем сервер, подключенный на 10 мегабит/c в Европе. Это распространенное заблуждение.Маркетологи из хостинг-компаний используют магию цифр. Конечно, скорость 100 мегабит/c на порядок больше, чем 10 мегабит/с. По этой причине у клиента появляется ложное ощущение, что такой хостинг будет намного лучше, а сайт на таком сервере будет работать быстрее. Маркетологи умышленно преподносят «толщину» канала чуть ли не как самый важный параметр при выборе хостинга.
В реальности подключение сервера к 100-мегабитному порту вовсе не является гарантией качества хостинга. Дело в том, что заявленная скорость в 100 Мбит/с является таковой только внутри дата-центра хостинг-провайдера. Чуть меньшая, но тоже высокая скорость будет в близких сегментах сети, которые подключены по пирингу. Если же хостинг-площадка находится очень далеко от пользователя, то в этом случае реальная скорость оказывается гораздо меньше.
Реальная скорость загрузки с конкретного сервера для конкретного пользователя определяется самым узким местом в цепочке от сервера до пользователя. Так вот, этим «слабым звеном» почти никогда не бывает сетевая карта сервера, пусть она будет на 10 Мбит/с, на 100 Мбит/с или на 1 Гбит/с.
Загрузить стомегабитный порт сервера на полную мощность практически невозможно, потому что «узким местом» является вовсе не он, а каналы за пределами дата-центра. Это может быть внешний канал, по которому дата-центр подключен к интернету, а также другие участки сети, по которой передается трафик.
Весь трафик от сервера можно разделить на четыре типа. Они отличаются не только по дальности передачи, но и по стоимости:
1) трафик внутри дата-центра;
2) пиринговый трафик;
3) национальный трафик;
4) международный трафик.
Трафик внутри дата-центра
Трафик внутри дата-центра — это тот трафик, которым сервер обменивается со своими «соседями» по хостинг-площадке. Обычно скорость обмена данными внутри площадки равна скорости порта подключения, то есть 10 или 100 Мбит/c. Как правило, хостинг-провайдеры включают этот трафик в счет на оплату наравне со всеми остальными типами трафика. Однако, ряд провайдеров предлагает так называемый «выделенный VLAN». В этом случае трафик между серверами, находящимися в одном и том же дата-центре, в итоговый счет включен не будет.
Пиринговый трафик
Все интернет- и хостинг-провайдеры стараются подключиться к пиринговым точкам, через которые происходит бесплатный обмен трафиком между ними. Это делается с целью уменьшения количества трафика, проходящего через бэкбоны, то есть сети первичных провайдеров (такие как Teleglobe, Level3, Verio и другие). Пиринг позволяет уменьшить цены на трафик, снижает нагрузку на бэкбоны и значительно увеличивает скорость передачи информации.
Если клиент, просматривающий ваш сайт, находится в сети участника пиринга, то трафик попадет к нему, минуя сети первичных провайдеров. Это благоприятно сказывается и на стоимости трафика, и на скорости загрузки веб-страниц.
Национальный трафик
Стоимость национального трафика обычно ниже, чем стоимость международного трафика. У провайдеров есть возможность наращивать свои канальные мощности внутри страны путем введения в строй новых оптических каналов. Кроме того, как отмечено выше, обычно национальные провайдеры подключены к различным пиринговым точкам. Международные каналы развиваются медленнее. Естественно, что международный трафик стоит дороже. Кроме того, удаленность от пользователя негативно влияет на пинг к серверу.
Международный трафик
Данный тип трафика самый дорогой, так как идет по сетям провайдеров первого уровня. Например, трафик из Беларуси в Новую Зеландию проходит через сети двух провайдеров первого уровня: Teleglobe и AT&T. Цену на данный тип трафика можно посмотреть на сайтах первичных провайдеров. Она составляет от $35 до $200 за в месяц мегабит/c, в зависимости от условий соглашения. Таким образом, «труба» в 100 мегабит в сети первичного провайдера обойдется в 5-20 тысяч долларов. Именно такие деньги нужно заплатить за гарантированную полосу пропускания в 100 мегабит/с.
Также каналы можно разделить на гарантированные и негарантированные. Каналы с гарантированной полосой пропускания подразумевают, что за клиентом закрепляется определенная ширина канала, которая гарантирует ему возможность использовать максимум полосы в любое время суток вне зависимости от загрузки канала провайдера. Каналы с негарантированной полосой пропускания позволяют использовать максимум полосы только в те моменты, когда большая часть остальных клиентов провайдера ее не использует.
Провайдерский бизнес позволяет существенно экономить на каналах за счет неравномерной нагрузки производимой на каналы пользователями. Этим занимаются, как провайдеры доступа, так и хостинг-провайдеры. Такая ситуация позволяет не только существенно сэкономить на каналах, но и предлагать небольших клиентам более низкие цены на каналы и трафик.
Даже самые крупные хостинг-провайдеры стараются сэкономить на трафике и каналах. Управляя несколькими тысячами серверов, они арендуют каналы из расчета около 1 Мбит/с на один порт для выделенного сервера, и это в лучшем случае. Очень часто зарезервированная полоса составляет всего 0,5 мегабита/c на 1 сервер. Такое возможно из-за неравномерной одновременной нагрзуки производимой серверами на каналы.
Известна история, например, про американского хостера EV1servers.net. Пару лет назад у них в дата-центрах было установлено более 20.000 серверов с портами по 100 Мбит/c каждый. Все серверы использовали один канал всего на 14 гигабит/с, что соответствует 0,7 мегабит/с на 1 сервер (сейчас они проапгрейдились). И это один из лучших дата-центров в мире. Наверняка, у многих других хостеров, как американских, так и российских, ситуация гораздо хуже. О каких же 100 Мбит/с можно тогда говорить? Неудивительно, что многие клиенты хостинга жалуются, что заявленная на их сервере скорость в 100 Мбит/с таковой не оказывается в критический момент.
Для более наглядной иллюстрации ситуации с каналами можно рассмотреть пример белорусских провайдеров доступа в Интернет. Уже сегодня белорусские провайдеры имеют сотни и даже тысячи клиентов, которые подключены к сети провайдера на достаточно высоких скоростях по технологии xDSL. При этом внешние каналы белорусских провайдеров имеют полосу пропускания во много раз ниже суммарной полосы, которую они продают клиентам. Те клиенты, которые подключены на высоких скоростях (более 1 мегабита/c) наверняка заметили, что заявленная провайдерами скорость подключения не соответствует скорости, которую они получают при скачивании файлов извне Беларуси. В особенности это становится заметно по вечерам, когда большинство пользователей-потребителей трафика приходит домой и начинает загружать каналы провайдера.
Цена на такие каналы также отличается. Белтелеком продает оптом каналы с гарантированной полосой пропускания 1 мегабит/c по цене около $1100 долларов в месяц, а клиенты провайдеров получают домой 1 мегабит/c пусть и ограничениями по трафику за цену уже многим менее $100 в месяц.
Теперь становится понятно, что 100-мегабитный порт в США, то никак не может гарантировать пользователю в Беларуси или России скорость, даже близкую к этому показателю в особенности, если за этот порт платится низкая цена у провайдера экономящего на качестве трафика. В условиях, когда гарантированная полоса пропускания стоит намного дороже негарантированной полосы, маркетинговый слоган о «100-мегабитном канале» означает лишь то, что сетевая карта сервера включена в порт провайдера со скоростью 100 мегабит/c. Дата-центры не гарантируют такую скорость даже на выходе из своей собственной сети, не говоря уже о международном трафике.
Про хостинг-провайдеров, которые рассказывают о хостинге на канале измеряемом во многих гигабитах/c мы скромно умолчим. Или вы знаете сетевую карту, которая передает данные на скорости выше 1 гигабита/c?
Анатолий Ализар
Материал подготовлен при содействии хостинг-провайдера «Экстмедиа»
Миф третий. Круглосуточная техподдержка
Опубликовано 25 Ноябрь 2007 в: 4 хостинг мифа
Наверное, где-то существуют хостинг-компании, которые обеспечивают оперативную и профессиональную техническую поддержку по телефону, IM и электронной почте 24 часа в сутки 7 дней в неделю. Однако, в большинстве случаев «круглосуточная поддержка» — это миф и не более чем рекламный лозунг.
Специфика служб техподдержки хостинговых операторов связана со спецификой этого вида бизнеса. Серверы работают круглосуточно, а клиенты находятся в разных уголках мира и в разных часовых поясах. Общение происходит, главным образом, по электронной почте и IM-пейджеру. Люди обращаются за помощью 24 часа в сутки.
В такой ситуации вполне естественно, что хостинговые компании пытаются привлечь пользователей гарантией «круглосуточной технической и информационной поддержки».
Что скрывается за этим рекламным лозунгом в реальности? Иногда за ним скрывается включенный факс, который работает всю ночь. Иногда - малограмотный студент, который согласился работать в ночную смену. Он может решить только самые простые вопросы и бесполезен в большинстве ситуаций.
Нужно понимать, что техническая поддержка клиента осуществляется на нескольких уровнях.
Первый уровень. С клиентами по телефону и ICQ чаще всего общаются сотрудники самой нижней ступени, максимальная компетенция которых - зачитать голосом FAQ или передать информацию в вышестоящую инстанцию. Среди всех специалистов компании это наименее грамотные. Даже крупные хостинговые операторы платят им нищенскую зарплату, так что серьезной помощи от них ожидать не приходится. При любом нестандартном вопросе эти сотрудники отправляют клиента к администратору.
Второй уровень. Технические администраторы (админы), которые непосредственно занимаются обслуживанием серверов, тоже вынуждены общаться с клиентами, если проблему не способны решить сотрудники первого уровня. Технические Админы тоже обычно работают круглосуточно, но они не всегда доступны, потому что общение с клиентом - не основная их задача. Кроме того, они могут решить только технические вопросы.
Третий уровень. Руководители служб и супервизоры принимают самые ответственные решения о включении сервера, об отсрочке оплаты и т.д. Они практически никогда не работают ночью. Например, если сервер отключили по жалобе, то администратор никогда не включит его обратно, хотя имеет такую возможность. Он будет ждать, пока руководитель проснется, придет на работу и примет такое решение.
Другими словами, даже при формальном наличии круглосуточной техподдержки, на практике все вопросы решаются только в дневное время.
Впрочем, даже простейшую проблему не всегда удается решить ночью. Некоторые компании гарантируют, что ICQ техподдержки работает 24 часа в сутки. На практике так оно и есть - «аська» в онлайне, но почему-то часами не отвечает ни на какие вопросы (вот один такой случай). Уж лучше бы она вообще не работала, чем впустую тратила время клиента.
Только самые крупные компании способны обеспечить реальную техподдержку ночью, но даже у них нет гарантии, что вы получите ответ в течение нескольких часов. Служба техподдержки крупных хостеров практически никогда не работает через IM. Это связано с тем, что невозможно надежно идентифицировать клиента (клиент потом может сказать, что сообщения писал не он - и такие случаи бывали), поэтому нельзя сообщить конфиденциальную информацию.
Крупные компании отказываются от IM-пейджеров в пользу специализированных систем онлайнового общения с клиентами типа LiveSupport. Это некий гибрид форума, чата и IM. Но опять же, только самые «продвинутые» компании ставят такие системы для круглосуточного обслуживания клиентов, и даже это не способно гарантировать качество сервиса.
В любом случае, ночью можно решить далеко не все те же вопросы, что и днем. Хотя бы потому, что на работе не присутствуют руководители компании, бухгалтерия, администратор. «Круглосуточная поддержка» - это в любом случае миф, потому что уровень сервиса днем и уровень сервиса ночью отличаются у любой компании. Они никак не могут быть равноценны. Во многих случаях, как мы уже упомянули, ночная поддержка - фикция.
Пожалуй, лучше всех это знает витеблянин Артем Лабода, который запустил в интернете уникальный эксперимент по проверке служб техподдержки хостинговых компаний. Вся переписка со всеми службами поддержки выложена на сервере в структурированном виде: название хостинг-компании, текст вопроса, текст ответа и, самое главное, - время отправки вопроса и получения ответа. Собрана внушительная база данных.
Хотя эксперимент не научный, но его результаты весьма красноречивы и говорят сами за себя. Как мелкие хостинговые компании, так и крупные зачастую отвечают на письма с огромной задержкой. Например, документально зафиксированы задержки ответов в 11 часов, 12 часов, 14 часов и даже 17 часов. Нельзя назвать такие ситуации редкими. Подобное встречается сплошь и рядом, особенно, если письмо в техподдержку отправлено ночью.
Более того, статистика «Мониторинга поддержки» показывает, что операторы хостинговых компаний вообще никогда не работают круглосуточно. Замер времени, когда их аккаунты ICQ находятся в онлайне (специальный скрипт ежеминутно пингует номера ICQ), показывает, что даже лидеры не могут гарантировать круглосуточную доступность.
Операторы лучших служб техподдержки находятся в онлайне от 15 до 22 часов в сутки. Лучший результат - 22,9 ч (статистика за 15 октября 2006 г.). Результат хороший, но это все равно не «круглосуточная поддержка», которую обещает реклама.
«Безусловно, понятие «круглосуточная поддержка» существует, однако, подавляющее большинство хостинг-провайдеров используют термин только для привлечения клиентов, - рассказал нам Артем Лабода в личной переписке. - Главные страницы сайтов таких провайдеров пестрят заголовками «24 часа», «круглосуточная поддержка» и т.п. величиной с рекламный баннер. В действительности, такие хостинг-провайдеры отвечают через несколько часов - и это замечательно, потому что часто ответа получить не удается вообще! Когда я захожу на сайт незнакомого хостинг-провайдера и нахожу строгие временные рамки работы службы поддержки («8.00 - 20.00 МСК»), это меня привлекает». К словам эксперта нечего добавить. Круглосуточная службами поддержка у хостинг-провайдеров - не более, чем миф, и это известно каждому, кто много общался с этими службами.
Анатолий Ализар
Материал подготовлен при содействии хостинг-провайдера «Экстмедиа»
Миф четвертый. Ежедневный бэкап
Опубликовано 25 Ноябрь 2007 в: 4 хостинг мифа
Многие хостинг-провайдеры обещают «ежедневный бэкап» и заверяют нас в том, что на всех серверах установлены RAID-массивы, которые гарантируют сохранность информации. Непонятно только одно: почему после аварий в дата-центрах данные оказываются безвозвратно утеряны? А ведь таких случаев много.
Хостинг-провайдеры особенно любят фразу «ежедневный бэкап». Они считают, что эта фраза является исчерпывающей сама по себе и не требует никаких пояснений. На сайтах хостеров редко встретишь подробное описание самой процедуры восстановления данных.
На самом деле, когда доходит до восстановления вашего сайта из бэкапа, то оказывается, что не всегда восстановление возможно. В одном случае приходится уговаривать администратора, потому что восстановление по первому требованию не предусмотрено в договоре. В другом случае вам не дают выбрать, из какой копии восстановить. А в третьем случае и вовсе восстанавливать нечего — никакой информации не сохранилось. Почему так?
Гарантируя «ежедневный бэкап», хостер обещает каждый день делать копии вашей информации. Тут возникает целый ряд вопросов.
1. Сколько дней хранится копия? Один день или больше?
2. Где именно хранится копия? На том же сервере или на отдельном?
3. В каком случае вам разрешено восстановить данные?
К сожалению, не всегда ответы на эти вопросы становятся очевидными из маркетинговых лозунгов хостинг-компаний. Каждый из перечисленных пунктов имеет подводные камни, о которых принято умалчивать.
Давайте посмотрим, что скрывается за мифом о ежедневном бэкапе.
Как долго хранится копия
Главный секрет хостинг-провайдера — то, сколько дней хранится информация. Согласитесь, очень мало толку от ежедневного бэкапа, если копия хранится всего один день. Поэтому нужно обязательно узнать, как долго хранится каждая копия.
В случае потери информации вам надо успеть восстановить ее из резервной копии в течение того срока, пока хранится бэкап. Если архивы хранятся, например, семь дней, то нужно заметить потерю и восстановить копию в течение семи дней с момента происшествия. Если же хостер не говорит, в течение какого срока хранятся копии, то здесь явно что-то не чисто. Высока вероятность, что эти копии хранятся всего 24 часа, как это бывает у абсолютного большинства хостинг провайдеров, так что после очередного «ежедневного бэкапа» все ваши файлы будут потеряны навсегда.
Нужно заметить, что у зарубежных хостинг-провайдеров услуга резервного копирования почти всегда является платной. В этом случае у клиента в панели управления часто присутствует пункт «Резервное копирование», так что он может в любой момент сделать копирование «за свой счет», то есть самостоятельно и, часто, на свой локальный компьютер. Осуществлять эту процедуру можно как угодно часто, а восстанавливать сайт клиент потом будет тоже самостоятельно.
В некоторых ситуациях самостоятельный бэкап надежнее автоматического, который делает (или обещает делать) хостинг-провайдер. Однако при этом возникает вопрос — куда скачивать информацию? При больших объемах скачивать на свой домашний компьютер может оказаться очень дорого и долго. «Складировать» на тот же диск опасно. При физическом повреждении диска вы потеряете не только сайт, но и его бэкап. Видимо, разумнее всего «сливать» бэкап на сервер по соседству. И, несмотря на то, что расходы на хостинг при этом могут удвоиться, чувствовать вы себя будете намного спокойнее.
Если вы надеетесь на автоматический бэкап хостера, то обязательно узнайте у него все подробности. В нормальной системе резервного копирования хранятся бэкап-копии как минимум за последние семь дней, а клиент получает право восстановить систему из бэкапа за любой день, на его выбор. Бывает, что за отдельную плату срок хранения архивов можно продлить (каждая «дополнительная» неделя стоит около $10 в месяц).
Где именно хранится копия
Здесь возможны варианты. Говоря о бэкапе, компания может подразумевать всего лишь то, что в сервере установлено несколько жестких дисков, объединенных в RAID-массив.
В принципе, наличие RAID-массива является большим плюсом, потому что надежность хранения информации при этом может возрасти на порядок. Как известно, большинство типов RAID-систем (Redundant Array of Independent Disks, то есть «избыточный массив независимых дисков») предусматривают дублирование информации на нескольких жестких дисках. Если вдруг какой-то диск выходит из строя, то его меняют без перезагрузки сервера («горячая замена»), а информация на лету восстанавливается из копии. При этом используются самые обычные жесткие диски, которые объединяются в кластер с помощью специального RAID-контроллера.
Однако, нужно заметить, что массивы RAID бывают разных типов (RAID 0, 1, 2, 3, 4 и 5), все они отличаются друг от друга по уровню надежности и другим характеристикам. В частности, стандарт RAID 0 не предусматривает избыточного копирования информации вообще. Несколько жестких дисков используются только для повышения производительности. То есть использование RAID-массивов само по себе не гарантирует сохранность информации.
Некоторые компании, которые исповедуют параноидальную политику по обеспечению сохранности информации, избегают устанавливать в один узел RAID-массива жесткие диски одинаковых производителей. Связано это с тем, что диски одного производителя имеют одинаковое время наработки на отказ и одинаковый показатель вероятности выхода из строя, что дает повод остерегаться того, что оба жестких диска выйдут из строя одновременно.
Кроме того, даже самые надежные RAID-массивы никоим образом не могут выполнять функцию резервного копирования. Они помогают только при физической порче одного из винчестеров, но никак не в случае взломов или случайного повреждения данных самим клиентом. Если клиент или служба поддержки замечают взлом или повреждение данных позже обычного времени архивации, то в зеркале RAID им будет доступна уже поврежденная или взломанная версия.
Да и от логических сбоев в файловой системе RAID-массив также не спасает. В случае если файловая система даст сбой, то наиболее вероятно, что придется восстанавливать полностью всю систему.
Полноценный бэкап возможен только в том случае, если данные копируются в отдельное хранилище, например, на отдельный сервер (бэкап-сервер).
Если вы сами делаете резервное копирование, то архив может храниться там, где выберете вы сами, в том числе на вашем домашнем компьютере. В любом случае, чтобы там не говорил провайдер о резервном копировании, желательно иметь копию сайта у себя на компьютере и периодически ее обновлять.
Поэтому следующий вопрос, который нужно задать вашему хостеру — где именно хранится бэкап? На RAID-массиве, отдельном диске или на том же диске, где расположен сам сайт? В случае хранения бэкапа на отдельном диске, стоит поинтересоваться, а не имеет ли к этому диску доступ кто-нибудь помимо администратора хостера? Ответ даст вам некоторое представление о защите вашего бэкапа от уничтожения посредством взлома расположенного на том же диске сайта.
Вариант для самостоятельного бэкапа
Не так давно известная интернет-компания Amazon запустила платформу удаленного хранения файлов Amazon S3 (Simple Storage Service). Данный сервис позволяет закачивать информацию в дата-центры Amazon и хранить ее там сколь угодно долго. При этом цены на размещение информации в разы дешевле стоимости хранения данных у хостеров. В месяц за хранение каждого гигабайта данных нужно будет заплатить по 15 центов, а за трафик — по 20 центов за гигабайт. В большинстве дата-центров и на большинстве хостинг-площадок обычная цена хранения резервных данных составляет не менее $1 за гигабайт в месяц, то есть почти в семь раз дороже.
В каком случае вам дадут восстановить данные
Как ни странно, но типичный договор с хостинг-провайдером содержит пункт, согласно которому восстановление информации из резервной копии возможно только в том случае, если авария произошла по вине провайдера. Если же информация была потеряна по вашей вине (например, некий злоумышленник узнал ваш пароль, проник в систему и стер все файлы), то восстанавливать ее из бэкапа хостинг-провайдер не обязан. Собственно, хостера можно понять — восстановление из бэкапа производится вручную и требует некоторых усилий. Почему же компания должна отвечать за безалаберность клиента?
Справедливости ради скажем, что во многих случаях ситуацию можно разрешить, если позвонить в компанию и вежливо попросить системных администраторов о помощи. Иногда они идут навстречу клиентам и соглашаются осуществить восстановление бесплатно. В остальных случаях обычно можно сделать бэкап за небольшую плату ($25-50 за час работы системного администратора).
Но нужно понимать, что если в вашем договоре не прописана четко обязанность хостера предоставить вам бэкап по первому вашему требованию, хостер, который предоставляет свои услуги слишком дешево, скорее всего вам откажет или потребует денег. Стоит ли говорить о ваших правах в случае, если хостер работает по договору публичной оферты? Т.е. попросту без договора. Будьте уверены, в этом случае «админ» будет либо занят, либо в плохом настроении — и вы, скорее всего, останетесь ни с чем.
Shit happens
Несмотря на то, что почти каждый хостинг-провайдер уверяет нас в «ежедневном бэкапе» информации, очень многие попадали в неприятные истории.
Пожалуй, самый крупный скандал с потерей данных случился летом нынешнего года с участием российского хостинг-провайдера Valuehost . 30 июня 2006 г. в результате сбоя в дата-центре были полностью или частично удалены около 500 сайтов. Как стало известно потом, сбой заключался в отказе одного из жестких дисков на одном-единственном сервере.
В случае с Valuehost правда вышла наружу. Оказывалось, что на серверах не было контролеров RAID, а резервное копирование или вообще не осуществлялось, или по каким-то причинам прошло неудачно. Итог известен.
Что характерно, компания Valuehost не понесла абсолютно никакой ответственности. В договоре на хостинг было особо отмечено, что хостинг-провайдер не несет никакой ответственности за сохранность данных. Это стандартный пункт для многих договоров на услуги хостинга. Выглядит он примерно так:
«5.3. Исполнитель предоставляет Услугу «как есть», т.е. не несет никакой ответственности за любой прямой и косвенный ущерб, вызванный технологическими причинами объективного и субъективного характера.»
Печально, что истинное положение вещей с резервным копированием в хостинг-компаниях мы зачастую узнаем только тогда, когда исправить что-либо уже невозможно.