- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
К нам можно прийти с 22-мя рублями и получить качественный сервис.
И даже саппорт полноценный получить?;)
22 рубля - пол бутылки дешевого пива есть смысл делать дешевле?
Ну, вот у меня, к примеру, 200 говносайтов. По 22 рубля за сайт было бы просто безумного дорого, я плачу на порядок меньше;)
И даже саппорт полноценный получить?;)
Кстати очень даже полноценный.
Ну, вот у меня, к примеру, 200 говносайтов. По 22 рубля за сайт было бы просто безумного дорого, я плачу на порядок меньше;)
Ориентироваться на все аудитории невозможно. Мы заняли нишу - обычных среднестатистических пользователей. Средний клиент имеет по 2-3 сайта средней нагрузки. Тогда это дешево для клиента.
Ваша ситуация очень схожа с сателитчиками - много легковесных сайтов. Тогда размещаться у нас получается не выгодно. С другой стороны, если мы сменим ориентацию на сателитчиков, то не сможем давать столько ресурсов обычным пользователям. Так как обычных пользователей больше, чем сателлитчиков, то мы решили ориентироваться на них.
Для тех, у кого десятки сайтов есть реселлерский тариф. Он намного удобнее и немножко дешевле - 18 рублей за сайт. Но он все равно считется виртхостами, а Вам выгодно, чтобы Вас считали например дисковым пространством.
Олег! Не все тебе одному на троне королем сидеть :p
:D Я никогда не называл себя лучшим ))))
:D Я никогда не называл себя лучшим ))))
У тебя репы много ))) Репу за просто так не сыпят.
Я подозреваю, что твой хостинг тоже устойчив.
Роман, при всем желании поделиться к сожалению рассказать детали не могу. Мы все же друг друга хоть и уважаем, но конкуренты.
Могу лишь сказать, что существует технология (и она общедоступна и бесплатна для 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 или есть оптические стореджи?
Мы кстати через два месяца начнем писать свою панель. Точнее платформу. Это немножко больше чем панель. И аппаратная часть нас будет интересовать. Нужно будет списаться попозже.
Да, можно будет попробовать!
Итого имеем:
1. Патч к ядру, какой-то grsec наверное :)
2. Бекапная сеть между серверами участниками сети.
3. А как с конфигами если они динамические например ? Синхронизация какая-то?
4. Переписанные init срипты для запуска грейсфул перед reload ?
А как же происходит репликация контента? если его объемы например ну 10GB на пользователя? Все по прежнему over ethernet или есть оптические стореджи?
1. Неа. grsecurity это вроде патч на SSH. А то что у нас - не патч, а встроенная функция переделанная своими патчами.
2. Так точно. Бэкапы машины тоже хранятся на ее паре.
3. Нет никакой синхронизации. Только симлинки. Потому что парные конфиги служат для перехвата вэб-сервера чужого траффика (от соседской ноды), но не для восстановления битой версии. Потому что восстановлением битой версии тоже занимается инит-скрипт. Он же делает конфигтест перед релоадом и если переменная $? не равно нулю, то тупо достает с бэкапа (который сделал пердыдущий инит-скрипт) целую версию и выкладывает.
4. В том числе да. Но не ради этого. А ради того, чтобы 1) нгинкс не уперся в ребутающийся апач (ИСП иногда именно restart дает вместо reload) и 2) апач не сделал релоад с битого конфига.
Репликации контента у нас, к сожалению нет. Этим мы сможем похвастать только в своей панели.
То есть если кто-то заденет ногой электрический провод сервера - сайт все-таки лягут. Кластеризуются только отдельные сервисы.
Тогда это не самый стабильный хостинг. 😂
1. Неа. grsecurity это вроде патч на SSH. А то что у нас - не патч, а встроенная функция переделанная своими патчами.
2. Так точно. Бэкапы машины тоже хранятся на ее паре.
3. Нет никакой синхронизации. Только симлинки. Потому что парные конфиги служат для перехвата вэб-сервера чужого траффика (от соседской ноды), но не для восстановления битой версии. Потому что восстановлением битой версии тоже занимается инит-скрипт. Он же делает конфигтест перед релоадом и если переменная $? не равно нулю, то тупо достает с бэкапа (который сделал пердыдущий инит-скрипт) целую версию и выкладывает.
4. В том числе да. Но не ради этого. А ради того, чтобы 1) нгинкс не уперся в ребутающийся апач (ИСП иногда именно restart дает вместо reload) и 2) апач не сделал релоад с битого конфига.
Репликации контента у нас, к сожалению нет. Этим мы сможем похвастать только в своей панели.
То есть если кто-то заденет ногой электрический провод сервера - сайт все-таки лягут. Кластеризуются только отдельные сервисы.
А на сколько узлов по топологии layer2 удалены ноды друг от друга?
Тогда это не самый стабильный хостинг. 😂
Ну учитывая, что на сегодня не существует хостингов без единой точки отказа - мы не проигрываем тут. Все в одинаковом анусе :)
А на сколько узлов по топологии layer2 удалены ноды друг от друга?
Немного не понял вопрос. В моем понимании Layer2 - это либо L2TP либо просто канальный уровень в OSI.
Первое не применимо по понятным причинам. На второе ответить не смогу, потому что хопы можно считать только с третьего уровня. Если с третьего - то по-русски между ними два хопа (везде 1Gb/s)
Ну учитывая, что на сегодня не существует хостингов без единой точки отказа - мы не проигрываем тут. Все в одинаковом анусе :)
Немного не понял вопрос. В моем понимании Layer2 - это либо L2TP либо просто канальный уровень в OSI.
Первое не применимо по понятным причинам. На второе ответить не смогу, потому что хопы можно считать только с третьего уровня. Если с третьего - то по-русски между ними два хопа (везде 1Gb/s)
Я про OSI, ну все машинки в 1 свич воткнуты? т.е свич помер и вся схема лесом или есть ноды например физически в разных DC? имел ввиду кол-во маршрутизаторов \ коммутаторов между нодами.