14/12/2012
Qlory77:
Согласен с Вами полностью на словах выглядит всё очень просто, а на деле оказывается масса проблем.
Тут есть ещё проблема: давайте смоделируем ситуацию к примеру произошел сбой на Сервере А мы сделали редирект на сервер Б. Сервер А недоступен 1 час. Соответственно люди делают заказы n-ое кол-во, n-ое кол-во людей зарегестрировалось и n-ое кол-во изменений цен в товарах было. Соответственно заработал сервер А мы убрали редирект, но заказы остались на сервере Б. Даже если при заказе писать в 2 БД тем самым делать их зеркалами, то как делать когда один из серверов недоступен и запись в MYSQL или SQLite не возможно сделать.
Другой вопрос когда всё хранится на одном сервере а база данных хранится в другом месте откуда оба сервера подгружают информацию.
Согласен с Вами полностью на словах выглядит всё очень просто, а на деле оказывается масса проблем.
Тут есть ещё проблема: давайте смоделируем ситуацию к примеру произошел сбой на Сервере А мы сделали редирект на сервер Б. Сервер А недоступен 1 час. Соответственно люди делают заказы n-ое кол-во, n-ое кол-во людей зарегестрировалось и n-ое кол-во изменений цен в товарах было. Соответственно заработал сервер А мы убрали редирект, но заказы остались на сервере Б. Даже если при заказе писать в 2 БД тем самым делать их зеркалами, то как делать когда один из серверов недоступен и запись в MYSQL или SQLite не возможно сделать.
Другой вопрос когда всё хранится на одном сервере а база данных хранится в другом месте откуда оба сервера подгружают информацию.
Да, конечно, я и говорю что непросто. Все эти особенности нужно учитывать при настройке репликации баз данных и файлов, а также в регламенте восстановления после сбоев. Есть, например, такая проблема с репликацией - она запаздывает, и это тоже нужно учитывать. А если делать репликацию мастер-мастер, будут задержки при добавлении данных. И это только часть проблем...
Так называемая бесшовная отказоустойчивость, когда при отказах оборудования все транзакции успешно завершаются, требует отдельного проектирования. А оборудование и настройка обойдется в копеечку...
25/01/2013
Мне кажется в теме отмычкой пытаются чинить шатл.
Если проект настолько большой, что идет речь о размещении двух сервеверов в разных дата-центрах, мне кажется, это как минимум не совсем рационально.
Во-первых в такой ситуации проект оптимально размещать не на двух серверах в двух датацентрах, а на кластерной системе, отдельные сегменты которой будут зеркалировать друг-друга, помимо этого они могут (и будут) географическими зеркалами для посетиетелей.
Во вторых, касательно дублирования данных. Разумеется, в таких системах базы данных крутятся на отдельных ciscoвских железках оптимизированных под работу БД. И если и нагибаются сервера, то падают именно веб-сервера, обслуживающие запросы, но не сегмент данных. Серверов бд тоже может быть не 1, если речь идет о разнесенном по географии проекте, а может быть 1 главный и несколько второстепенных (по странам). Между сегментами часто прокладывается быстрый VPN для административных и не только задач.
К вопросу про "сервер А и сервер Б" - если заказы прошли, они лежат на уровне данных и остались доступными, - отвалился только сервер А и запросы пошли на свободные Б и С, которые хранят данные на едином сервере D.
Касательно вопроса тс про хостинг магазина на сетевом хранилище.
upd.
Не будет.
Не будем лезть в технические детали и характеристики устройства, - просто, поверьте, не стоит. Предпочтение стоит отдать недорогой одноюнитовой железяке (если нужно в стойку) под один проект средней нагрузки (потянет 5, 10 и 20000 пользователей в сутки, если мы ведем речь о типичном ИМ и стандартных задачах железки под него) Её можно взять за 32-36 т.р.
http://www.servershop.ru/detail_14921.htm
http://www.servershop.ru/server.php?pag ... t&det=7342
http://www.depo.ru/config_depo_c1750_i137938_m2.aspx
Дешевле могут быть некоторые асусы и интелы. DELL и к примеру HP под эти задачи брать не вижу смысла, так как при почти аналогичной конфигурации обойдутся уже в 2000$ и дороже.
Указанное тс устройство, его конфигурация, помимо слабого процессора в силу своих задач имеет нерасширяемый объем ОЗУ (512) и прочие ограничения, связанными с приоритетом перегонки и хранения данных. Вообще на железной составляющей проекта лучше не экономить и брать серверы с ориентацией на задачи проекта на год-два вперед.
Если проект настолько большой, что идет речь о размещении двух сервеверов в разных дата-центрах, мне кажется, это как минимум не совсем рационально.
Во-первых в такой ситуации проект оптимально размещать не на двух серверах в двух датацентрах, а на кластерной системе, отдельные сегменты которой будут зеркалировать друг-друга, помимо этого они могут (и будут) географическими зеркалами для посетиетелей.
Во вторых, касательно дублирования данных. Разумеется, в таких системах базы данных крутятся на отдельных ciscoвских железках оптимизированных под работу БД. И если и нагибаются сервера, то падают именно веб-сервера, обслуживающие запросы, но не сегмент данных. Серверов бд тоже может быть не 1, если речь идет о разнесенном по географии проекте, а может быть 1 главный и несколько второстепенных (по странам). Между сегментами часто прокладывается быстрый VPN для административных и не только задач.
К вопросу про "сервер А и сервер Б" - если заказы прошли, они лежат на уровне данных и остались доступными, - отвалился только сервер А и запросы пошли на свободные Б и С, которые хранят данные на едином сервере D.
Касательно вопроса тс про хостинг магазина на сетевом хранилище.
upd.
Цитата:
Сайт думайте не будет шустрее крутится
Сайт думайте не будет шустрее крутится
Не будет.
Не будем лезть в технические детали и характеристики устройства, - просто, поверьте, не стоит. Предпочтение стоит отдать недорогой одноюнитовой железяке (если нужно в стойку) под один проект средней нагрузки (потянет 5, 10 и 20000 пользователей в сутки, если мы ведем речь о типичном ИМ и стандартных задачах железки под него) Её можно взять за 32-36 т.р.
http://www.servershop.ru/detail_14921.htm
http://www.servershop.ru/server.php?pag ... t&det=7342
http://www.depo.ru/config_depo_c1750_i137938_m2.aspx
Дешевле могут быть некоторые асусы и интелы. DELL и к примеру HP под эти задачи брать не вижу смысла, так как при почти аналогичной конфигурации обойдутся уже в 2000$ и дороже.
Указанное тс устройство, его конфигурация, помимо слабого процессора в силу своих задач имеет нерасширяемый объем ОЗУ (512) и прочие ограничения, связанными с приоритетом перегонки и хранения данных. Вообще на железной составляющей проекта лучше не экономить и брать серверы с ориентацией на задачи проекта на год-два вперед.
Ответить
Читайте также
08/02/2021
Для интернет-магазина необходимо подобрать хостинг, который позволит всем системам работать быстро. Какие виды хостинга есть? Как выбрать подходящий? Платный или бесплатный?...
Подробнее