это пролексик считает себя лучшим на рынке 😂
kostich добавил 11.04.2009 в 08:40
Можно к нам. Контакты и краткое описание проекта скидывайте в Л.С. Лицензии на предоставление услуг связи в РФ N65024 и N65025. Договора можно подписать в офисе у столичных партнеров или по почте.
ps. с анонимными клиентам не работаем.
гопники vs жопники или жопники vs гопники...
100 мегабит бандвича уже штуку евро стоят 😂
200 - две
300 - три
...
ps. а потом идут сказки про 5 гигабитные ддосы.
2Абудда: поскриптум про рынок в целом... про тех кто цену от размера атаки выставляет.
Статику на тест сетапнуть можем... панель мож к весне там допишут. У нас просто есть возможность с таким балансингом клиенту отдавать нужное количество дедиков в разных точках, а этот рынок нам пока более интересен.
Кластер в рамках одного ДЦ не имеет какого либо смысла, кроме как для выдерживания более большей нагрузки... а если падаёт, то падает конкретно. При географическом разнесении скорость доступа юзеров возрастает, а распределение трафика на уровне BGP гарантирует что в штатном режиме пользователи с конкретного IP будут всегда попадать на конкретную физическую ноду. В случае выведения ноды из системы происходит перестроение маршрутов и следующая TCP сессия пользователя придет на следующую ближайшую ноды. В схеме есть конечно же минусы, но большую часть мы преодолели достаточно давно. В ДЦ где трафика приходит больше доставляются дополнительные ноды, которые моментально включаются в схему распределения трафика. Массштабируется достаточно гибко.
Имеет смысл строить распределенную систему.
Мы разносим по разным странам из-за разной стоимости и качества трафика. При этом трафик к посетителям идёт не только быстрым путём, но еще и самым дешевым. Последнее гарантируется распределением трафика на уровне протокола маршрутизации BGP. У многих провайдеров транзит для конечного потребителя подзашейплен, но с IXов они позволяют качать практически любой полосой.
Он для этого не годится.
Задача несколько шире, чем просто разнесение, т.к. СУБД гарантирует целостность данных и атомарность каких-то операций. Это значит, что если при разрыве связи между нодами потребуются атомарные операции (ограничение, работа с уникальными ключами), то СУБД не сможет их гарантировать. В случае если эти ограничения жестко обойти, то после восстановления связи произойдёт коллизия, которая должна будет разгребаться руками администраторов базы с участием заинтерисованных в целостности данных лиц.
Если делать всё на уровне приложений, то представьте себе ситуацию, что посетитель из РФ работал с базой на сервере в РФ. В какой-то момент происходит сбой у его провайдера и маршрут автоматически пролегает до сервера в Европе или США. Представьте себе какие коллизии могут произойти, в том случае если данные от РФ еще не реплицировались на остальные сервера... а если еще и сервер в РФ оторвался полностью, то... то пользователь может повторно зарегистрироваться, потерять корзину, удалить что-то лишнее... и т.д.
На уровне шареда мы предлагаем только статику. Если речь идёт о динамике, то это не хостинг уже, а разработка или портирование решения заказчика и т.д. Последнее дорого.
а айпишники точно их?
ps. а то к нам тут из тулы ходили уже гуглботы.
да это как раз понятно... а вот msn, гугль и про что там еще вещали... короче они туда физически дойти не могли.
лежало там всё полностью и ничего туда ходить не могло... в данный момент заработало.
