- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Интересует продуманная схема простой и продуманной архитектуры, которая может вырасти в высоко нагруженную систему.
Для начала может быть все на одном сервере, а дальше уже по необходимости.
Я предполагаю такую схему:
На железо накатывается прослойка в лице proxmox ve или ovirt/
Создаются виртуальные машины, каждая с минимальной настройкой и единственным функционалом
- балансер
- сервер приложения
- база данных
- файловый сервер
Ваши предложения/рассуждения по этому поводу?
Используй обычную архитектуру. А когда придет время, выкинь ее и перепиши со всеми вышеперечисленными страшными словами.
Постоянно возникают подобные темы. И постоянно выясняется, что не имея широкого инженерного опыта выгодней просто своевременно переезжать на сервер покруче.
Поддержу предыдущего оратора. Не нужно переусложнять работающую систему просто "чтобы было".
А вот ваше работающее приложение можно и нужно писать (или подбирать, если речь о CMS), держа в уме дальнейшую возможность адаптации творения под что-то подобное.
Вы пишете второй вконтакте или яндекс?
Какого рода и посещаемости сайт вы делаете?
По моей оценке сайт с посещаемостью до 5-10 миллионов кликов к страницам в сутки будет нормально работать на стандартной системе на мощном сервере без каких то особых заморочек.
У меня один сервер держит около 5 миллионов запросов в сутки к тяжелым страницам PHP.
Load average 0.5
Если будут тормоза, то можно будет mysql или апаче на отдельный сервер поставить.
Вопрос архитектуры большого сайта – весьма сложный и сходу на него не ответить.
Нужно, пробовать, тестировать, много думать.
А я за разнос по виртуалкам, одна машина - одна задача. Масштабируется легче, управляется легче.. Опять таки паппет порекламирую - виртуалки руками не настраивать, а автоматом... Мониторинг автоматом на основе паппетовых классов собирать, бекап...
Ну разумеется это все имеет смысл если в обозримой перспективе оно будет разрастаться. Если пока не понятно - то соглашусь с предыдущими ораторами
Ну скажем есть потенциал до 10 млн. просмотров точно есть, больше как вложимся.
Ну скажем есть потенциал до 10 млн. просмотров точно есть, больше как вложимся.
Я когда делал один из первых сайтов, вообще думал дата-центр придется строить, ничего, обошлось.
Ну я не сказал что пишу вконтакт же? :), а назвал адекватное число, оцененное по счетчикам конкурентов.
UnnamedUA, ну, допустим, есть еще одна разумная переходная ступень между одним сервером и кластером : одна задача - один диск (или массив).
Вычислительные мощности современных процессоров превосходят потребности веба за исключением некоторых узких задач.
В хороший сервер можно набить 6-8 дисков,два физических процессора и памяти довольно много.
При этом нагрузка ввода-вывода будет распределяться по дискам, но вы будете избавлены от сложных проблем синхронизации в сети.
Есть много простых и доступных способов распределить нагрузку на несколько серверов, прежде чем городить огород со сложными системами.
1) Вынести отдачу статики на отдельные сервера
2) Вынести mysql на отдельные сервера. С помощью репликации mysql распределить БД на несколько серверов.
3) Вынести апач на отдельный сервер.
4) Сделать несколько фронтендов nginx которые будут проксировать на один бэкенд. Между фронтендами сделать балансировку нагрузки с помощью ДНС.
Думаю, что эти доступные методы позволят держать нагрузку в десятки миллионов запросов в сутки. Наверное, даже вконтакте такая система выдержит. А если и этого будет мало, то значит вы создали второй яндекс. И денег у вас миллионы.
Вам уже всё расписали, в принципе.
Простейшие схемы на будущее:
1) Отдельный сервер баз данных, отдельный сервер с проектом. Вообще никаких проблем в реализации.
2) nginx + apache на одном сервере. На нём же прописан в nginx второй сервер как бэкенд (балансировка).
Файлы дублируются на втором сервере. Вариантов здесь несколько:
а) DRBD
б) rsync (самый простой в реализации вариант)
в) NFS и т.п.
Так же 3-й сервер используется под базы данных.