- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Да ничего там сложного нет... за исключением mysql, который нельзя разнести по разным ДЦ.
все в этом мире относительно...
для вас, как для специалиста в этой области, возможно и нет в этом сложностей...
а как же штатный mysql cluster?
а как же штатный mysql cluster?
Он для этого не годится.
Задача несколько шире, чем просто разнесение, т.к. СУБД гарантирует целостность данных и атомарность каких-то операций. Это значит, что если при разрыве связи между нодами потребуются атомарные операции (ограничение, работа с уникальными ключами), то СУБД не сможет их гарантировать. В случае если эти ограничения жестко обойти, то после восстановления связи произойдёт коллизия, которая должна будет разгребаться руками администраторов базы с участием заинтерисованных в целостности данных лиц.
Если делать всё на уровне приложений, то представьте себе ситуацию, что посетитель из РФ работал с базой на сервере в РФ. В какой-то момент происходит сбой у его провайдера и маршрут автоматически пролегает до сервера в Европе или США. Представьте себе какие коллизии могут произойти, в том случае если данные от РФ еще не реплицировались на остальные сервера... а если еще и сервер в РФ оторвался полностью, то... то пользователь может повторно зарегистрироваться, потерять корзину, удалить что-то лишнее... и т.д.
На уровне шареда мы предлагаем только статику. Если речь идёт о динамике, то это не хостинг уже, а разработка или портирование решения заказчика и т.д. Последнее дорого.
Как говорил kostich, имеет смысл Кластер только, если сервера разнесены по разным дата-центрам - не у всех дата-центров аптайм 100% и если добится аптайма 100% у сервера, то бидно будет получить 99% у самого дата-центра. С другой стороны, я бы лично предпочел строить кластерную систему в пределах одной страны (например в Украине высокая скорость между серверами обеспечена UA-IX), но с разными кальными провайдерами.
Как говорил kostich, имеет смысл Кластер только, если сервера разнесены по разным дата-центрам
Имеет смысл строить распределенную систему.
Мы разносим по разным странам из-за разной стоимости и качества трафика. При этом трафик к посетителям идёт не только быстрым путём, но еще и самым дешевым. Последнее гарантируется распределением трафика на уровне протокола маршрутизации BGP. У многих провайдеров транзит для конечного потребителя подзашейплен, но с IXов они позволяют качать практически любой полосой.
Семь лет пользую другой кластерный хостинг (кластер из 30 серверов) - аптайм отнюдь не стопроцентный - и даже не рекордный, хотя и неплохой
так скажи те какой
abudda добавил 30.01.2009 в 15:06
Мы под статику только предлагаем. Особенность кластера в том, что ноды стоят в мск, питере, амстере, франкфурте, стокгольме, лондоне, ny, лосанжелесе и т.д... для 100% месясного аптайма обычно достаточно мск и франкфурта.
я так понимаю вы геокластер предлагаете, но я использую в основном цмс для построения всех проектов и там достаточно динами, думаю геокластер не подойдет для этих целей.
abudda добавил 30.01.2009 в 15:07
abudda, что именно Вам требуется?
Как правильно заметил kod_ssilki_ru, кластерный хостинг понятие растяжимое и может использоватся для самых разных целей.
Если интересует именно высокая доступность, могу предложить серьезное решение на основе HP DISA с полным зеркалированием всех систем и пр. (SLA %99.999), обращайтесь.
можно где-то ознакомится на стрнаице с вашим решением? урл?
abudda добавил 30.01.2009 в 15:18
При этом трафик к посетителям идёт не только быстрым путём, но еще и самым дешевым. /QUOTE]
вот тут вижу парадокс,м обычно самый дешевый не явлается самым быстрым.
Для своих же целей я особо не зацыкливался на подобных вешах, я говорил о обычном кластере из нескольких машин, которые обеспечивали бы непрерывность работы моего сайта. Я реалист и понимаю, что 100% меня не ждет ниг-де, кроме как сетевой кеш :) если обновления подспепеют во-время.
Но в хостинге, мне понравиль решение от хостпро, если бы сервер еше в европе стояли, вопросов не было бы
abudda, а почему тогда не к нам? Или расположение серверов критично?
MySQL можно без проблем разнести в кластер и работать с ним на уровне клиентов.
Я уже писал здесь на форуме как это реализовывается в самом простом варианте.
Единственное что нужно чтобы ПО клиента было ориентировано на кластерность.
Синхронизация с защитой от коллизий делается довольно просто и не доставляет много труда.
У нас в кластерном пространстве по такой схеме работает в том числе 3 MySQL сервера(Питер, Киев, Франкфурт).
Конечно если таких серверов больше, скажем 10, то это будет чуточку сложнее и дольше при синхронизации, но не более.
Кстати у нас SaaS CMS-хостинг работающий на этом кластере, но пока не публичный. :)
abudda, а почему тогда не к нам? Или расположение серверов критично?
Так может вы тут сразу и расскажете о своем кластере?
я так понимаю вы геокластер предлагаете, но я использую в основном цмс для построения всех проектов и там достаточно динами, думаю геокластер не подойдет для этих целей.
Кластер в рамках одного ДЦ не имеет какого либо смысла, кроме как для выдерживания более большей нагрузки... а если падаёт, то падает конкретно. При географическом разнесении скорость доступа юзеров возрастает, а распределение трафика на уровне BGP гарантирует что в штатном режиме пользователи с конкретного IP будут всегда попадать на конкретную физическую ноду. В случае выведения ноды из системы происходит перестроение маршрутов и следующая TCP сессия пользователя придет на следующую ближайшую ноды. В схеме есть конечно же минусы, но большую часть мы преодолели достаточно давно. В ДЦ где трафика приходит больше доставляются дополнительные ноды, которые моментально включаются в схему распределения трафика. Массштабируется достаточно гибко.