- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Вы говорите о какой-то "грамотной инфраструктуре".. вы конкретней можете?
Система управления хостингом. Пресловутая "панелька", в частности.
Админы? А что админы, да, есть админы к которым я обращаюсь за помощью когда нужно, все с этого форума кстати.
У семи нянек дитя без глазу...
Поэтому хочется кластера, что если один падает, клиенты "уходили" на другой работающий сервер. И даже если это будет 2-3 сервера — это уже вполне отказоустойчивое решение.
Это прежде всего дорогое решение. Во-первых - потребует постоянных услуг квалифицированного администратора. А во-вторых, удвоит стоимость оборудования (покуда у Вас реально 2-3 сервера). Хостинг весьма не бюджетный будет.
А чего вдруг падают-то?
Ок, наверное общее SCSI хранилише для всех БД серверов — это я погорячился :) В целом я имел ввиду, что с виду для разработчика это одна БД.
hacccker добавил 03.12.2010 в 04:55
Система управления хостингом. Пресловутая "панелька", в частности.
У семи нянек дитя без глазу...
Это прежде всего дорогое решение. Во-первых - потребует постоянных услуг квалифицированного администратора. А во-вторых, удвоит стоимость оборудования (покуда у Вас реально 2-3 сервера). Хостинг весьма не бюджетный будет.
А чего вдруг падают-то?
Панелька сейчас ISP manager со всеми вытекающими. Жутко не нравится, но пока как есть.
"дорогое" решение — понятие растяжимое, разумеется за настройку админу я готов платить. А покупать дорогие продукты вроде ISP manager Cluster я не готов. И даже если бы был готов, всёравно искал бы альтернативные решения, т.к. продукты ISP меня не устраивают своими глюками.
>А чего вдруг падают-то?
К чему эти глупые вопросы? Падают потому что ломаются, потому что бывают программные сбои.
>потребует постоянных услуг квалифицированного администратора...
Что-то я смогу сделать сам, что не смогу — обращусь к квалифицированным администраторам.
Ок, наверное общее SCSI хранилише для всех БД серверов — это я погорячился :)
Хотя есть такое теоретическое предположение, что можно это реализовать, если mysql-сервер будет работать одновременно один. Т.е. общее хранилище и с ним работает один сервер MySQL. В случае его падения (сгорел или что-то ещё), запускается mysql-server c другого сервера и продолжает работать базами из хранилища. (при этом подхватывает ip-адрес упавшего и даже ничего не нужно в сриптах менять.). Только вот базы лучше заранее проверить на сбои перед запуском второго mysql.
Himiko, вот вы как крутой одмин, имейте прямое отношение к author-media.ru и предоставляйте услугу виртуального хостинга. Просвятите меня пожалуйста, как вы проектировали архитектуру. У вас есть сервер(а), что если один сервер падает? Ну хз, блок питания сгорел, сетевая карта ещё хрень какая-то... Ваши клиенты ждут пока сотрудники ДЦ заменят оборудования?
hacccker добавил 03.12.2010 в 05:08
Хотя есть такое теоретическое предположение, что можно это реализовать, если mysql-сервер будет работать одновременно один. Т.е. общее хранилище и с ним работает один сервер MySQL. В случае его падения (сгорел или что-то ещё), запускается mysql-server c другого сервера и продолжает работать базами из хранилища. (при этом подхватывает ip-адрес упавшего и даже ничего не нужно в сриптах менять.). Только вот базы лучше заранее проверить на сбои перед запуском второго mysql.
Наверное примерно так MySQL Cluster и работает.
Ваши клиенты ждут пока сотрудники ДЦ заменят оборудования?
Либо всё взлетает на другом сервере из резервных данных.
Если вы про кластер, то в данный момент у нас его нет. Задумки есть, но пока есть технически не реализованные вещи.
Himiko добавил 03.12.2010 в 05:26
Наверное примерно так MySQL Cluster и работает.
Не так. С кластерезацией mysql там вообще песня отдельная. Это по-моему один из самых больших "головняков" в web-кластере (если не под конкретный проект, а под хостиг).
Имхо до появления MySQL Cluster это действительно был страшный головняк, но сейчас то все достаточно просто. Я понимаю, что мои теоретические знания о MySQL Cluster могут не покрывать все практические аспекты, но тем не менее очень интересно, почему вы считайте, что MySQL Cluster это головняк для веба, и чем принципиально отличается MySQL Cluster под отдельные проект и под хостинг.
к примеру, это обсуждалось здесь http://forum.ispsystem.com/ru/showthread.php?t=4083&page=2
Цитирую:
интересно, почему бы не поставить центральный биллинг и кучу серверов, биллинг будет управлять этими серверами, на сервераз ISP manager или что-то другое, зачем тут нужен именно кластер?
rtyug, у такой схемы низкий порог масштабируемости. Он думает, что один аккаунт начнет потреблять столько ресурсов, что единичного сервера не хватит. Ну и надежности повышенной хочется.
Но я думаю, что такой клиент просто сбежит, чем будет платить за специальный супертариф кластерного виртуального хостинга. Такому клиенту выгодней арендовать выделенный сервер и заняться оптимизацией. На своем сервере это гораздо удобнее.
Какое дело они говорят? :) Ничего конкретного. Pavel.Odintsov советуют хранить все-все-все на одном сервере, V(o)ViK советует начать построение кластера с выбора панели... 🍿
Я советую начать с составления ТЗ и бюджета 🚬