• Главная
  • Карта сайта
Не найдено

Що таке хостинг? У чому відмінність різних хостингів і як вибрати правильну компанію?


Багато, починаючі користувачі мережі інтернет рано чи пізно приходять до питання «А що таке хостинг?».
У цій статті ми відповімо на це питання і опишемо стандартні рішення Хостингу, які існують на даний момент, а також розповімо про те, як це влаштовано в нашій компанії ТОВ «Хостінговиє Телесистеми» www.hts.ru

Хостинг - це технічний майданчик для розміщення сайтів, що надається спеціалізованими Хостинг компаніями. По-простому - це місце, де лежать сайти. Робота Хостинг компанії зводиться до того, щоб надавати безперервний (в ідеалі) доступ користувачів інтернет до сайтів, розміщених в даній хостингових компаній.

Послуги Хостингу можна розділити на:
  • Віртуальний Хостинг (або просто Хостинг);
  • Віртуальний виділений сервер (або VPS, він же VDS);
  • Оренда виділеного сервера.
Чим можуть відрізнятися Хостінговиє компанії, на що варто звернути увагу при виборі?
  • Дуже просто і в той же час складно відповісти на дане питання. Зазвичай для більшості першим фактором є, звичайно, ціна послуги. Але якщо вивчити це питання, порівняти різні пропозиції, то в умовах ринку і досить великої кількості Хостинг-Провайдерів можна прийти до висновку, що ціни дуже схожі.
  • Хорошим радою буде подивитися відгуки про хостингових компаній, що думають інші? Відсутність відгуків показує, що компанія нова, зазвичай таких обходять стороною. Присутність тільки позитивних відгуків теж насторожує, в середньостатистичній компанії завжди будуть різні думки, потрібно їх вивчити і спробувати зрозуміти, прийти до проміжного висновку про компанію. І після цього задатися питанням про якість надаваних послуг хостингу, і підході хостингової компанії до реалізації хостингу.
  • Вкрай важливим є цілодобова і професійна, компетентна підтримка хостингу, щоб можна було в будь-який момент зателефонувати, списатися і вирішити виниклі проблеми зараз, а не вранці в понеділок.
  • Щоб забезпечити високу швидкість і надійність сайтів і виключити перебої в роботі, хостинг провайдер повинен володіти найсучаснішим і якісним обладнанням. Необхідно переконатися що ваш провайдер здатний миттєво запустити резервні потужності для компенсації будь-якого збою, будь то проблеми з електроенергією, маршрутами зв'язку, перегрів обладнання або локальні проблеми безпосередньо на сайтах.
  • Запорукою успіху хостингової компанії є власний Дата-центр (ЦОД), який укомплектований дорогим обладнанням і відповідає найвищим сучасним стандартам якості. Багато компаній, що не мають власного Дата-центру, орендують обладнання в найбільших Дата-центрах Москви або Санкт-Петербурга. Мінуси такої схеми роботи в тому, що вільний доступ в такі Центри обмежений, і, якщо щось зламалося, потрібно виписувати пропуск, їхати туди, вирішувати проблему самостійно. Все це збільшує час простою сайтів, що негативно відбивається на seo-просуванні і ефективності рекламної кампанії або SMM, що проводяться в даний період. Відповідно привабливість послуг, що надаються віртуального хостингу такими компаніями знижується.

А тепер, давайте розглянемо технічні варіанти реалізації хостингу.

Перший варіант створення хостингу - це взяти звичайний сервер і розмістити всі сервіси на ньому, в більшості випадків це типове рішення для кількох сайтів, не вимагає багато витрат, всі сервіси розміщені разом, такі як: веб сервер, сервер баз, поштова система.


(Рис. 1)

Більш складний варіант - це коли сервіс бази даних виноситься на окремий сервер, тобто навантаження на обробку запитів до бази даних винесена на окремий сервер, тим самим розвантажуючи безпосередньо сервер контенту і пошти.


(Рис. 2)

Ще складніше система, коли всі основні сервіси рознесені по окремих фізичних серверів, не заважаючи один одному в роботі.


(Рис. 3)

У всіх вище перерахованих систем є свої мінуси і плюси.
Наприклад, на Мал. 1 все знаходиться на одному сервері, зручно адмініструвати і контролювати, але це також дає і мінуси. Припустимо, на сервер починає надходити безліч запитів, яке змушує сервер генерувати динамічний контент, причому для створення контенту потрібно задіяти ресурси бази даних, так ось в цьому випадку при поганій розробці може статися досить неприємний казус.
Суть його в тому, що прийшов запит на веб-сервер породжує запит до бази даних, який з різних причин може виконуватися досить довгий час, при цьому споживаючи досить велика кількість ресурсів системи в цілому. І так приходить ще один запит на веб-сервер, і ще, і ще, в результаті сервер працює все повільніше і повільніше, намагаючись обробити всі запити. В результаті робота всього сервера буде паралізована, і навіть користувачі, які запросять контент не пов'язана з динамічною конфігурацією, можуть його і не отримати через перевантаженої системи.

Другий варіант ( Мал. 2 ) На перший погляд вирішує проблеми першого випадку, але тут можна отримати іншу проблему. Якось в своїй практиці, я спостерігав роботу CMS-системи, яка вимагала виконати близько 17000 запитів до бази даних. У зв'язку з тим, що на обробку одного запиту до бази йшло менше 0.01 сек., В сумі це виходило близько 120-200 секунд, що, в общем-то, зовсім не прийнятно. Якщо сторінка сайту буде відкриватися більш, ніж декількох секунд, скоріш за все відвідувач покине сайт. На цьому прикладі я показав, що при великій кількості запитів до бази даних, накладні витрати, як б не помітні в більшості випадків, викликають дуже велику проблему.
А ось як раз в першому випадку ( Мал. 1 ) Запити могли б виконуватися раз в 10 швидше, так як було б витрачено набагато менше мережевих служб, так як запити проходили безпосередньо через мережевий стек операційної системи.

Третій варіант ( Мал. 3 ) Здається взагалі ідеалом досконалості, адміністраторові треба контролювати вже три сервера, у кожного з яких можуть бути свої проблеми, які можуть вплинути на роботу всього комплексу. Хоча звичайно вже все краще, якщо раптом вас завалить Спамом, і поштовий сервер не витримає, сайт (и) будуть працювати як і раніше, це їм не завадить.

Ви можете подумати, як же легко зробити систему для хостингу сайтів, великих витрат не потрібно. В Інтернеті досить багато вільних або платних систем управління серверами, які дозволяють не вдаватися в тонкощі системного адміністрування. Так погоджуся, при невеликій кількості сайтів і не великий активності на них у вас все буде працювати штатно, і ви можете спати спокійно.

Сюрпризи вас чекатимуть трохи пізніше, припустимо, один із сайтів починає рости і стає вельми популярним і вам доведеться робити вибір, або ви б'єтеся з ранку до вечора над стабільною роботою всієї системи, або вам доведеться відмовити власнику популярного ресурсу, щоб зберегти нормальну роботу інших ресурсів.

Звичайно, ви можете навантажений ресурс розмістити на іншому сервері, відокремивши його від всіх інших клієнтів. Але знову ж вам потрібно буде купити ще комплект обладнання і бути готовим, що тепер парк серверів у вас став більше і за всім цим господарством треба стежити, вчасно доповідати вам про збої які відбуваються і своєчасно вживати необхідних заходів для стабілізації різних ситуацій.

До всіх наших ресурсів варто додати нові системи, системи моніторингу, які, до речі, теж вимагають спостереження за собою.

На перший погляд життя налагоджується, але, на жаль, це ще не всі сюрпризи, чим більше стає клієнтів, тим більше навантаження на системи, і може трапитися так, що одного сервера баз даних буде не достатньо, необхідна установка нового.
Клієнти не особливо прагнуть вникати в мистецтво програмування і допускають досить серйозні помилки, які викликають перевантаження систем. Як у нас прийнято іноді говорити: «На таких серверах можна смажити яєчню» :-)

Ви встаєте перед вибором, що ж робити далі?
Що робити далі, це досить складне питання, оскільки він зав'язаний, як і на комерційній частині, так і на морально-етичної, я думаю це тема окремої статті, де можна філософствувати над усіма аспектами даного питання.

Повернемося ж до технічних питань. «Що можна ще поліпшити?» - запитаєте ви. В принципі немає меж досконалості, давай для початку розділимо вашу систему на дві частини «front-end» і «back-end» ( Мал. 4 )


(Рис. 4)

Всі запити приходять на «front-end» і далі цим сервером розподіляються між іншими «back-end» серверами. Можна подумати яка ж це хороша схема, а насправді, що буде, якщо «front-end» зламається? Правильно, ніяке кол-во «back-end» не допоможе врятувати ситуацію, якщо немає «front-end» сервера. Значить потрібно передбачити якийсь альтернативний варіант для такого випадку.

Для цього треба піднятися на рівень вище, на рівень маршрутизуючого обладнання, в те саме місце, куди на рівні IP дістався пакет в межі досяжності вашої системи, але ще не встиг дійти до ваших серверів і у вас є шанс втрутитися в процес, куди ж направити цей пакет.

До речі, це місце досить цікаве і має безліч рішень.
Як приклад, якщо у вас роутер має підтримку WCCP (Web Cache Communication Protocol), то можна використовувати його для цих цілей. Його суть зводитиметься до того, що якщо ваш «front-end» живий і регулярно відповідає на запити роутера або повідомляє його про своє життя, роутер перехоплює пакет і направляє його саме на «front-end». Якщо ж зв'язок з «front-end» загублена, то роутер направляє запити безпосередньо на один або безліч «back-end», все залежить від вашого бажання і види установок.

Навіть якщо у вас і немає дорогого роутера, то і тут залишається велике поле для дій. Звичайний сервер можна перетворити в роутер, використовуючи різні системи, такі як ipfw, iptables, pf можна досягти схожого результату, я б сказав навіть більшого, ніж в вище описаному випадку. Керувати правилами тут можете ви самі при написанні досить простих програмок. Якщо ж до цього ще й підключити, наприклад CARP (Common Address Redundancy Protocol), то можна зробити дубль такого сервера, в разі виходу з ладу одного сервера, роботу підхопить інший, тим самим збільшивши надійність системи в цілому.
Більш того, маючи перераховані вище системи, вам буде простіше боротися з такою частою проблемою останнім часом, як DDOS (Distributed Denial of Service). Так як ви не допустите попадання негативного трафіку на основні сервера системи, тим самим захистивши їх.

І знову виникло питання - «Що можна ще поліпшити?»
Та не проблема, давайте візьмемося за поштову систему, на першому етапі, коли ви ще все тільки починали, саме важливо не допустити простих помилок. Наприклад, для всіх поштових протоколів видати клієнтам одне і теж ім'я виду mail.domain.ru, все одно ж один сервер скажете ви. Але в подальшому в разі розширення вам доведеться складніше розділяти це ім'я по різних протоколах, тому не лінуйтеся, зробіть окремі імена на різні протоколи: smtp, pop, imap, навіть якщо вони поки і ведуть на один сервер.

Наступним кроком можна розділити протоколи smtp від pop і imap, причому для більшої надійності, можна розділити smtp на два окремих сервера для вхідної та вихідної пошти.
Так само зі збільшенням кількості вхідних та вихідних повідомлень, можна буде збільшувати кількість серверів smtp. У разі сервера вихідних повідомлень можна використовувати вказівку кількох ip адрес в dns сервері, і тоді за алгоритмом round-robin вихідний сервер клієнтом буде обиратися за принципом перебору адрес по круговому циклу, тим самим розподіляючи навантаження між серверами.

Точно так само можна вчинити і з серверами вхідної пошти, але у вас є ще один інструмент для управління процесом, куди ж доставляти пошту йде на домени ваших клієнтів. Цей параметр MX тип запису в dns, який вказує на mail-exchange сервера, які обслуговують пошту для домену. У цього типу записи можна вказувати пріоритет для кожного сервера або безлічі серверів, тим самим контролюючи в якому порядку і на який сервер буде доставлено лист для вашого клієнта.

Imap і pop протоколами трохи простіше, по суті, вони повинні жити поруч з досить великим сховищем пошти, щоб не лімітувати клієнтів розмірами ящиків. Тобто для цієї мети підійде будь-який сервер з великими дисками, в подальшому звичайно краще використовувати raid системи для надійного зберігання пошти, якщо ви будете брати з клієнтів гроші за це то ви повинні обов'язково задуматися про надійне зберігання.

З поштою розважилися, чим би нам зайнятися ще ...
І тут є теж варіанти, наприклад CRON (планувальник завдань для виконання ваших програм). Зазвичай в нього поміщають енергоємні і складні завдання по обробці якийсь аналітики або операцій обслуговування систем. І це може теж викликати проблему, якщо не по дискам, так по пам'яті або процесору, що може перешкодити видачі контенту з веб-сервера. Тут як варіант можна запропонувати наступне.

Файлову систему можна винести на інший сервер, наприклад по NFS, і на ньому обслуговувати cron завдання. Так само на цей сервер можна винести ssh доступ, так як робота цього сервера не пов'язана з роботою основного веб-сервера. Тут можна дозволити клієнтам користуватися різними програмами, які ви раніше не дозволяли використовувати, наприклад різні компілятори. Ftp немає сенсу сюди виносити, все ж завантаження файлів повинна бути ближче до сховища і як правило ftp не викликає проблем ні по диску, ні по процесору, ні по пам'яті.

Якщо стало знову нудно, то можна зайнятися модернізацією «back-end» серверів.
Найчастіше на таких серверах відбувається реконфігурація, щоб не змушувати цього робити, є кілька шляхів.
Перший - це створення віртуального мапінг імен сайтів, через шляху в файлової системі в яких фігуруватиме ім'я сайту, але в цьому випадку вкрай складно буде регулювати налаштування певних сайтів.
Другий варіант, це написання свого модуля який буде динамічно створювати і кешувати конфігурацію на основі бази даних. Тут теж не варто особливо захоплюватися, так як якщо вибрати базу даних mysql або pgsql, можна буде паралізувати або їх роботу або в разі їх поломки паралізувати роботу сайтів, тут краще використовувати або BDB або CDB. Тобто використовувати проміжну базу для зберігання налаштувань і оновлювати їх, якщо відбулися зміни в центральній базі.

Коли ви впоралися з вищеописаної завданням, то можна вибрати ще щось.
Давайте подумаємо, а як ми можемо всім сайтам давати при необхідності окремий ip адресу. Якщо у вас не один і не два сайти, а кілька тисяч, то виникає не проста ситуація. Треба прописати всі ip до певних сайтів, вельми не вражаюче заняття, крім прописування в конфігах веб-сервера треба прописувати це і в конфігах самої операційної системи, що навіть при деякій автоматизації, потім страшенно негарно буде виглядати.

Тут у себе ми вибрали трохи інше рішення, це створення reverse-proxy c хитрим мапінг, суть його зводиться до наступного, на роутері створюється маршрут для досить великої мережі, яка направляється на адресу нашого проксі сервера. На самому проксі сервер, прописується правило все пакети йде до нас в цій мережі перенаправляти в певний порт, причому саме перенаправляти, тобто залишаючи в пакетах інформацію про src і dst адресу. Далі наш проксі сервер, отримуючи цей пакет, бачить куди він спрямований, знову ж через проміжно сформований CDB файл, і визначає на якому з «back-end» знаходиться контент по даному запиту, направляє цей запит туди і передає відповідь клієнту.

За такою ж аналогією можна взагалі роздати всім сайтам IPV6 адреси, напевно в вашій базі, де зберігається список сайтів, у кожного сайту є свій унікальний числовий ідентифікатор, як правило, це integer, а це всього лише 32 біта, для ipv6 це суща дрібниця. Тобто на всі ваші витівки вистачить мережі / 96, 4 млрд. Адрес. :-)
Суть ідеї така, пакети перехоплюються і направляються знову ж в порт пуття сервера, тільки в цьому випадку ми беремо останні 4 байта адреси ipv6, які і є унікальний ідентифікатор сайту, далі не складе знову заглянути в базу і знайти, куди направити цей запит уже по верх ipv4.

Якщо вам ще не набридло все це читати, то в результаті ми отримаємо таку картину:

Багато, починаючі користувачі мережі інтернет рано чи пізно приходять до питання «А що таке хостинг?
Чим можуть відрізнятися Хостінговиє компанії, на що варто звернути увагу при виборі?
Хорошим радою буде подивитися відгуки про хостингових компаній, що думають інші?
«Що можна ще поліпшити?
Можна подумати яка ж це хороша схема, а насправді, що буде, якщо «front-end» зламається?
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью