- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Да ничего там сложного нет... за исключением 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 сессия пользователя придет на следующую ближайшую ноды. В схеме есть конечно же минусы, но большую часть мы преодолели достаточно давно. В ДЦ где трафика приходит больше доставляются дополнительные ноды, которые моментально включаются в схему распределения трафика. Массштабируется достаточно гибко.