bugsmoran: Он будет строиться на блейдах и на платформах (панель+распеределенная ФС+web-ферма+реплика СУБД и так далее) которые будут позволять исключать из системы на горячую любой блейд и апргрейдить/чинить его. Вот так вот смело предположил))
А почему "предположил" ??
Панель: В принципе любая + програмист
FS: lustreFS, glusterFS, zfs , уже как бы давно известны и пользуются
WEB: ферма из вебов это еще лет 5 назад пройденный этап, например железный балансировщик 4-7 layer, и как бы все, аналогично решается распределение запросов в SQL.
У нас на сегодня есть фермы более чем из 20 серверов.. которые надежно работают и заменяемы в любой момент, конечно это выглядит в виде все тех дедиков закрученных over ethernet и частично fiber . Сейчас работаю над синхронизацией cPanel.... вполне удачно можно сказать, есть конечно о чем еще подумать и доработать но тут прежде всего важна необходимость, а точнее потребность, многие сейчас думаю что вот cPanel ... как ее синхронизировать между 10ю серверами.... конфиги и все прочее, а на самом деле как показала практика панели достаточно только одной (на одном сервере) а остальные сервера реплицируют только сервисы, например httpd, а FS или распределенная или поверхностная синхронизация конфигов необходимых сервисов.
Сейчас больше заинтересовала возможность развести SELECT / INSERT по разным реплицируемым участкам кластера где есть SQL, я прекрасно понимаю как это сделать путем модификации исходного кода приложения которое будет работать с базой..... но не хотелось бы просить сотни клиентов переписать свои сайты ;))) А из промежуточных решений возникает только собственный драйвер который будет получать QUERY и разбираться (можно попробовать доработать существующий) что с ней сделать и куда отправить..... пробовал враперами простенькими - бред получился + некошерно с точки зрения нагрузки дополнительной ;)))
Я думаю что за этим будущее индустрии если честно!!!
gazmyas: Адалт
Нужно 10-20Гб места на диске с возможностью докупки через некоторое время еще 20-30Гб места.
Нормальний канал: чтобы скорость выгрузки по фтп была не меньше 50-70Кб\с и скорость скачки не меньше 150-200Кб\с
Поддержка докачки файлов. Желательно тестовый период (2-3дня) и впс с уже установленной хостинг-панелью
Зарегистрировать 5 доменных имен у одной конторы, а хостинг у другой.
Смогу ли я прикрутить эти имена к одному хостинг плану? Какие ждут трудности, а то я если чесно не представляю себе как это происходит,ибо раньше заказывал хост и 1 доменное имя у одной кампании,а там было все элементарно...
Проблем не будет, мало того многие так и делают, а мы как хостер так вообще регистрацией доменов не занимаемся во благо наших же клиентов :D
bugsmoran: А свитч же в транке стоит. Пусть помирает. Два линка с сервера выходит и в транковые свитчи (я это подсмотрел, когда в Comverse работал - там все так сделано). А так между ними два хопа - первый свитч, второй - парный сервер. Сейчас много криков начнется, что в случае пожара это все умрет и надо в соседние датацентры разносить :-D Предвосхищяя ликующие крики конкурентов сразу отвечу: не все датацентры горят. Есть и датацентры, где не отключают пожарку, если она дурит, а просто чинят ее )))) Hetzner еще ни разу не горел.
Не ну это паранойя, в случае пожара там хоть 20 свичей для резерва будет ничего не выживет, а горят таки все датацентры как ни странно..... только видимо каждый в свое время ;))))
Ну а что касается распределения я ж почему и спросил, ну допустим гореть там ничего не будет, возьмем по проще ситуацию, упал магистральный канал к примеру, есть альтернативы? куда включены? в какой AS находитесь? соседние AS ? сколько пирингов?
Romka_Kharkov добавил 19.07.2010 в 14:00
aeromouse: не люблю таких непотопляемых-неубиваемых суперхостеров. Не верю! (с)
Ну нафиг, я лучше на своём, старом, добром, с нормальным саппортом и серверами в Питере посижу.
Ну а вы что предполагаете, что технологии стоят на месте? уже есть скажем так прототипы, а в скором будущем найдутся магнаты которые перенесут все что у них есть на какую-то кластерную машинку из 10.000 серверов и на ней будут все ваши дедики, хостинги, и ВПС-ы вместе и все это будет сложно-потопляемо именно из за резервирования и повышения отказоустойчивости.
То, что может быть ТС о чем-то недоговаривает , это конечно его личное дело, но в принципе тенденция у него весьма правильная, так что не стоит плеваться, а иногда может быть просто надо попробовать!
bugsmoran: Ну учитывая, что на сегодня не существует хостингов без единой точки отказа - мы не проигрываем тут. Все в одинаковом анусе :)
Немного не понял вопрос. В моем понимании Layer2 - это либо L2TP либо просто канальный уровень в OSI.
Первое не применимо по понятным причинам. На второе ответить не смогу, потому что хопы можно считать только с третьего уровня. Если с третьего - то по-русски между ними два хопа (везде 1Gb/s)
Я про OSI, ну все машинки в 1 свич воткнуты? т.е свич помер и вся схема лесом или есть ноды например физически в разных DC? имел ввиду кол-во маршрутизаторов \ коммутаторов между нодами.
bugsmoran: 1. Неа. grsecurity это вроде патч на SSH. А то что у нас - не патч, а встроенная функция переделанная своими патчами.
2. Так точно. Бэкапы машины тоже хранятся на ее паре.
3. Нет никакой синхронизации. Только симлинки. Потому что парные конфиги служат для перехвата вэб-сервера чужого траффика (от соседской ноды), но не для восстановления битой версии. Потому что восстановлением битой версии тоже занимается инит-скрипт. Он же делает конфигтест перед релоадом и если переменная $? не равно нулю, то тупо достает с бэкапа (который сделал пердыдущий инит-скрипт) целую версию и выкладывает.
4. В том числе да. Но не ради этого. А ради того, чтобы 1) нгинкс не уперся в ребутающийся апач (ИСП иногда именно restart дает вместо reload) и 2) апач не сделал релоад с битого конфига.
Репликации контента у нас, к сожалению нет. Этим мы сможем похвастать только в своей панели.
То есть если кто-то заденет ногой электрический провод сервера - сайт все-таки лягут. Кластеризуются только отдельные сервисы.
А на сколько узлов по топологии layer2 удалены ноды друг от друга?
bugsmoran: Роман, при всем желании поделиться к сожалению рассказать детали не могу. Мы все же друг друга хоть и уважаем, но конкуренты.
Могу лишь сказать, что существует технология (и она общедоступна и бесплатна для Linux), которая позволяет ограничивать пользователей по времени CPU и RAM. Такая же технология кстати есть у FastVPS.ru и Bluehost/Hostmonster, но они так же не расскажут. Впрочем нужно много переписать в ядре, чтобы она заработало.
Что касается кластеризации. Каждый хостинговый сервер - на самом деле два сервера, скрепленных между собой backbone-сетью. Между ними есть MySQL-репликация ( нужна только на случай падения). Это опять же переписанный Tungsten Replicator. Впрочем не сильно переписанный.
С nginx и Apache все намного проще - двойной комплект конфигов на каждой ноде. Решение - откровенный неэффектный костыль, но вполне рабочее. И кстати заменены все инит-скрпиты. То есть например команда invoke-rc.d apache2 restart на самом деле даст сначала конфигтест, а затем релоад. Никаким рестартом там и не пахнет. Для рестарта есть команда, незнакомая для ISPmanager.
Ну и так далее везде понемножку подкручено.
Итого имеем:
1. Патч к ядру, какой-то grsec наверное :)
2. Бекапная сеть между серверами участниками сети.
3. А как с конфигами если они динамические например ? Синхронизация какая-то?
4. Переписанные init срипты для запуска грейсфул перед reload ?
А как же происходит репликация контента? если его объемы например ну 10GB на пользователя? Все по прежнему over ethernet или есть оптические стореджи?
bugsmoran:
Мы кстати через два месяца начнем писать свою панель. Точнее платформу. Это немножко больше чем панель. И аппаратная часть нас будет интересовать. Нужно будет списаться попозже.
Он будет строиться на блейдах и на платформах (панель+распеределенная ФС+web-ферма+реплика СУБД и так далее) которые будут позволять исключать из системы на горячую любой блейд и апргрейдить/чинить его.
Вот так вот смело предположил))
А почему "предположил" ??
Панель: В принципе любая + програмист
FS: lustreFS, glusterFS, zfs , уже как бы давно известны и пользуются
WEB: ферма из вебов это еще лет 5 назад пройденный этап, например железный балансировщик 4-7 layer, и как бы все, аналогично решается распределение запросов в SQL.
У нас на сегодня есть фермы более чем из 20 серверов.. которые надежно работают и заменяемы в любой момент, конечно это выглядит в виде все тех дедиков закрученных over ethernet и частично fiber . Сейчас работаю над синхронизацией cPanel.... вполне удачно можно сказать, есть конечно о чем еще подумать и доработать но тут прежде всего важна необходимость, а точнее потребность, многие сейчас думаю что вот cPanel ... как ее синхронизировать между 10ю серверами.... конфиги и все прочее, а на самом деле как показала практика панели достаточно только одной (на одном сервере) а остальные сервера реплицируют только сервисы, например httpd, а FS или распределенная или поверхностная синхронизация конфигов необходимых сервисов.
Сейчас больше заинтересовала возможность развести SELECT / INSERT по разным реплицируемым участкам кластера где есть SQL, я прекрасно понимаю как это сделать путем модификации исходного кода приложения которое будет работать с базой..... но не хотелось бы просить сотни клиентов переписать свои сайты ;))) А из промежуточных решений возникает только собственный драйвер который будет получать QUERY и разбираться (можно попробовать доработать существующий) что с ней сделать и куда отправить..... пробовал враперами простенькими - бред получился + некошерно с точки зрения нагрузки дополнительной ;)))
Я думаю что за этим будущее индустрии если честно!!!
Бесплатные Load Balacers
Расскажите подробнее что вы имеете ввиду? как реализована балансировка, чем?
Адалт
Нужно 10-20Гб места на диске с возможностью докупки через некоторое время еще 20-30Гб места.
Нормальний канал: чтобы скорость выгрузки по фтп была не меньше 50-70Кб\с и скорость скачки не меньше 150-200Кб\с
Поддержка докачки файлов. Желательно тестовый период (2-3дня) и впс с уже установленной хостинг-панелью
А обязательно VPS ? А если VIP-Hosting ?
ТС, может вам услуга Proxy нужна а не VPS целый?
Вообщем что я хочу:)
Зарегистрировать 5 доменных имен у одной конторы, а хостинг у другой.
Смогу ли я прикрутить эти имена к одному хостинг плану? Какие ждут трудности, а то я если чесно не представляю себе как это происходит,ибо раньше заказывал хост и 1 доменное имя у одной кампании,а там было все элементарно...
Проблем не будет, мало того многие так и делают, а мы как хостер так вообще регистрацией доменов не занимаемся во благо наших же клиентов :D
А свитч же в транке стоит. Пусть помирает. Два линка с сервера выходит и в транковые свитчи (я это подсмотрел, когда в Comverse работал - там все так сделано). А так между ними два хопа - первый свитч, второй - парный сервер. Сейчас много криков начнется, что в случае пожара это все умрет и надо в соседние датацентры разносить :-D Предвосхищяя ликующие крики конкурентов сразу отвечу: не все датацентры горят. Есть и датацентры, где не отключают пожарку, если она дурит, а просто чинят ее )))) Hetzner еще ни разу не горел.
Не ну это паранойя, в случае пожара там хоть 20 свичей для резерва будет ничего не выживет, а горят таки все датацентры как ни странно..... только видимо каждый в свое время ;))))
Ну а что касается распределения я ж почему и спросил, ну допустим гореть там ничего не будет, возьмем по проще ситуацию, упал магистральный канал к примеру, есть альтернативы? куда включены? в какой AS находитесь? соседние AS ? сколько пирингов?
Romka_Kharkov добавил 19.07.2010 в 14:00
не люблю таких непотопляемых-неубиваемых суперхостеров. Не верю! (с)
Ну нафиг, я лучше на своём, старом, добром, с нормальным саппортом и серверами в Питере посижу.
Ну а вы что предполагаете, что технологии стоят на месте? уже есть скажем так прототипы, а в скором будущем найдутся магнаты которые перенесут все что у них есть на какую-то кластерную машинку из 10.000 серверов и на ней будут все ваши дедики, хостинги, и ВПС-ы вместе и все это будет сложно-потопляемо именно из за резервирования и повышения отказоустойчивости.
То, что может быть ТС о чем-то недоговаривает , это конечно его личное дело, но в принципе тенденция у него весьма правильная, так что не стоит плеваться, а иногда может быть просто надо попробовать!
HDD 2x от 500
RAM от 8
Трафик от 5TB (100mb)
Для warez\adult. Не обязательно абузоустойчивые. Будут тока ссылки, можно будет удалять. Жду :)
Дополнительные винты в районе 15-20$ в зависимости от объема
===================================================
10Mbs Unmetered:
===================================================
Dual Core ATOM 330
2 GB RAM
200 GB HDD
$120.00 / month
DUAL-CORE E5200 2.50GHZ
2 GB RAM
300 GB HDD
$175.00 / month
INTEL CPU CORE 2 DUO E8400 3.00GHZ
4 GB RAM
500 GB HDD
$220.00 / month
2x XEON QUAD CORE E5410 2.33GHZ
8GB RAM
2 x 500GB HDD
$370.00 / month
===================================================
100Mbs Unmetered:
===================================================
Dual Core ATOM 330
2 GB RAM
200 GB HDD
$170.00 / month
DUAL-CORE E5200 2.50GHZ
2 GB RAM
300 GB HDD
$220.00 / month
INTEL CPU CORE 2 DUO E8400 3.00GHZ
4 GB RAM
500 GB HDD
$270.00 / month
2x XEON QUAD CORE E5410 2.33GHZ
8GB RAM
2 x 500GB HDD
$475.00 / month
Канал Unmetered на заявленной скорости, шаренный.
С Адалтом - все в порядке, если все 18+, с ссылками думаю тоже проблем не будет если адекватно будете убирать.
Ну учитывая, что на сегодня не существует хостингов без единой точки отказа - мы не проигрываем тут. Все в одинаковом анусе :)
Немного не понял вопрос. В моем понимании Layer2 - это либо L2TP либо просто канальный уровень в OSI.
Первое не применимо по понятным причинам. На второе ответить не смогу, потому что хопы можно считать только с третьего уровня. Если с третьего - то по-русски между ними два хопа (везде 1Gb/s)
Я про OSI, ну все машинки в 1 свич воткнуты? т.е свич помер и вся схема лесом или есть ноды например физически в разных DC? имел ввиду кол-во маршрутизаторов \ коммутаторов между нодами.
1. Неа. grsecurity это вроде патч на SSH. А то что у нас - не патч, а встроенная функция переделанная своими патчами.
2. Так точно. Бэкапы машины тоже хранятся на ее паре.
3. Нет никакой синхронизации. Только симлинки. Потому что парные конфиги служат для перехвата вэб-сервера чужого траффика (от соседской ноды), но не для восстановления битой версии. Потому что восстановлением битой версии тоже занимается инит-скрипт. Он же делает конфигтест перед релоадом и если переменная $? не равно нулю, то тупо достает с бэкапа (который сделал пердыдущий инит-скрипт) целую версию и выкладывает.
4. В том числе да. Но не ради этого. А ради того, чтобы 1) нгинкс не уперся в ребутающийся апач (ИСП иногда именно restart дает вместо reload) и 2) апач не сделал релоад с битого конфига.
Репликации контента у нас, к сожалению нет. Этим мы сможем похвастать только в своей панели.
То есть если кто-то заденет ногой электрический провод сервера - сайт все-таки лягут. Кластеризуются только отдельные сервисы.
А на сколько узлов по топологии layer2 удалены ноды друг от друга?
Роман, при всем желании поделиться к сожалению рассказать детали не могу. Мы все же друг друга хоть и уважаем, но конкуренты.
Могу лишь сказать, что существует технология (и она общедоступна и бесплатна для Linux), которая позволяет ограничивать пользователей по времени CPU и RAM. Такая же технология кстати есть у FastVPS.ru и Bluehost/Hostmonster, но они так же не расскажут. Впрочем нужно много переписать в ядре, чтобы она заработало.
Что касается кластеризации. Каждый хостинговый сервер - на самом деле два сервера, скрепленных между собой backbone-сетью. Между ними есть MySQL-репликация ( нужна только на случай падения). Это опять же переписанный Tungsten Replicator. Впрочем не сильно переписанный.
С nginx и Apache все намного проще - двойной комплект конфигов на каждой ноде. Решение - откровенный неэффектный костыль, но вполне рабочее. И кстати заменены все инит-скрпиты. То есть например команда invoke-rc.d apache2 restart на самом деле даст сначала конфигтест, а затем релоад. Никаким рестартом там и не пахнет. Для рестарта есть команда, незнакомая для ISPmanager.
Ну и так далее везде понемножку подкручено.
Итого имеем:
1. Патч к ядру, какой-то grsec наверное :)
2. Бекапная сеть между серверами участниками сети.
3. А как с конфигами если они динамические например ? Синхронизация какая-то?
4. Переписанные init срипты для запуска грейсфул перед reload ?
А как же происходит репликация контента? если его объемы например ну 10GB на пользователя? Все по прежнему over ethernet или есть оптические стореджи?
Мы кстати через два месяца начнем писать свою панель. Точнее платформу. Это немножко больше чем панель. И аппаратная часть нас будет интересовать. Нужно будет списаться попозже.
Да, можно будет попробовать!