Создание отказоустойчивого кластера для интернет-магазина (продолжение темы)

Почитайте, что пишет TC, у него явно не стандартные задачи шаред хостинга.

Его супер-мега-сложно-секрктное приложение может сильно удивиться при переключении между нодами. К тому же он хочет обслуживание с гарантиями по срокам решения проблем без предоставления административного доступа Даже при условии решения всех технических проблем, написания кучи хуков обрабатывающих внештатные ситуации и т.д. эта нештатная ситуация может оказаться такой, что предусмотреть ее появление заранее было невозможно. С трудом представляю алгоритм решения тогой проблемы. Я бы на такое не подписался ни при каких условиях.

Да, в договоре будут пункты о конфиденциальности, однако я вначале должен понять, что мне предлагают и узнать цены на все, а потом уже заключать договоры и предоставлять информацию.

Насколько я понимаю, состава системных сервисов и схемы их взаимодействия должно быть достаточно для подбора архитектуры кластера. А логика работы приложения - обычная логика интернет-магазина, ERP и CRM. Есть клиенты, заказы, товары, документы и еще несколько сотен сущностей, сотни таблиц базы данных и сотни классов. Описание всего этого в деталях - отдельная и очень сложная работа. Поэтому надо как-то сделать первоначальную оценку без детальной информации.

По моему представлению на сегодняшний день, после балансировщика должен идти кластер из двух-трех серверов, на которых будет апач и скрипты приложения. Эти серверы будут подключены через оптику к общему хранилищу данных. Еще пара серверов нужна для кластера MySQL (плюс управляющие серверы), аналогично для MongoDB. Memcached можно, видимо, запускать на тех серверах, где будет работать приложение, а Sphinx - где MySQL или на отдельных серверах.

Такая или почти такая архитектура предлагается и ISP Manager Cluster (в основе), только там нет общего хранилища, подключенного по оптике, а есть медленное хранилище NFS. Вот это хранилище меня и смущает в их предложении - не подойдет для высокой нагрузки.

Если у нас будет подобная архитектура кластера, мы сможем самостоятельно справиться с настройкой приложения, чтобы оно обращалось за нужными сервисами к нужным хостам. Установка кластера с балансировщиком на Linux, насколько я понимаю, не очень сложная задача и у меня есть предложения от людей, готовых сделать это. И по железу - поставщик, у которого мы обычно покупаем серверы, готов предложить нам все железо для кластеров и настроить балансировщик и кластер на RedHat или Scientific Linux.

Наибольшие проблемы мне представляются с кластером MySQL, т.к. видимо придется вносить изменения в приложение, чтобы учитывать особенности работы MySQL в режиме репликации. Но это мы сможем отладить на виртуалках.

У тс набор софта известен, ничего необычного. Все это будет работать на кластере.

А ситуации все просчитываются заранее и у меня никаких непредусмотренных ситуаций никогда не бывает. Это как хирургическая операция по пересадке сердца. По этому к опытным хирургам и ждут больные в очередях, что не каждый это может.

А для продукта ispmanager cluster уже написали. И не нужно ждать целый месяц как вы предлагаете.

Можете и десятую страницу тумана, обещаний и аналогий с хирургическими операциями развести, но кроме ispmanager cluster нормальных предложений не было.

Все прозрачно - читай, думай, плати,качай, устанавливай.

а ты не используй вообще подчиненный mysql сервер до того момента как упадет основной и тогда модифицировать приложение не понадобится.

ispmanager cluster предоставляет специальную прослойку для реализации этого момента.

вот заладил. а "хранилище" подключенное по оптике не будет разделяемым. сервера веб-ноды не смогут пользоваться одним и тем же диском одновременно.

Вот тут, если можно, поподробнее. Как тогда работают подобные кластеры с общим дисковым хранилищем?

По-моему никак не работают. Ну может быть это возможно с использованием специальных фирменных драйверов и сетевых протоколов, но по iscsi и с помощью оптических линков (FC) можно просто примонтировать в монопольном режиме некий виртуальный кусочек массива, который создается на основе физических дисков. На этом и все волшебство и преимущества SAN заканчиваются.

Я от Андрейки не смог добиться указания на конкретные железки, которые позволяют эту проблему обойти без использования NFS. Я так понял, он предлагает городить кластерную файловую систему на отдельных ПК с винтами, что в принципе сопоставимо по надежности с SAN, но по скорости как бы не медленнее NFS.

Кроме того, я не понимаю с чего вы взяли что NFS будет тормозить ? Не стану спорить с тем, что он будет медленнее FC, но так ли критично медленнее ? Если такое было бы то железки netapp его бы не поддерживали, а это не бытовые коробочки. Полно в сети официальных руководств как настроить vmware на nfs и на русском. Значит эта конфигурация вполне обычная. Они там пишут что потери в районе 5% по сравнению с FC. Хотя у vmware свой nfs-клиент. Возможно, он оптимизирован, но сервер то используется обычный !

Нет, у меня тоже нет опыта эксплуатации подобной системы, но если вы претендуете стать передовым магазином в своем сегменте, вам придется попробовать. Заранее неизвестно как именно на практике отличается характер вашей нагрузки дисковой подсистемы от других сайтов.

Идет огромное количество обращений к файлам с стороны витрины интернет-магазина и бекофиса. Сейчас все эти файлы лежат в кеше операционной системы в оперативной памяти, и быстро туда попадают с локального диска. А так будет задействован сетевой стек. Вообще я читал где-то на форумах отзывы о том, что начинаются тормоза в ISP Cluster, связанные именно с NFS. Точно не могу вспомнить, где читал.

Нагрузка будет только расти со временем, поэтому хотелось бы избавиться от потенциально узких мест.

что значит огромное? чем это замеряли ? чем обусловлено ?

с включенным php-акселератором обращений к файлам php обычно немного. Ну а обращение к файлам данных обычно не нужно.

Из SAN можно сделать набор РАЗДЕЛЬНЫХ дисков для каждой веб-ноды и раскопировать все файлы. Но это уже превращает стандартную для ispmanager задачу кластеризации произвольного вебприложения, во что-то специализированное, а значит усложняет задачу в несколько раз.

Вот я нашел ссылку http://forum.ispsystem.com/ru/showthread.php?t=9106, но и там как-то все невнятно. Может быть сеть перегружена. Может быть не попытались использовать последние версии NFS на tcp, Может быть NAS неудачный.

В этой же теме и успешные отзывы о NFS.

Есть еще кеширующая прослойка между монтированием и nfs - cachefs, но не понятно как это работает в общем случае при конкурентном доступе.

они все равно будут лежать в памяти

пока неясна ваша имеющаяся нагрузка, так что это все равно надо брать и пробовать

это слишком неопределенно. Задача должна звучать так, например: у нас такая-то нагрузка, систему мы хотим получить с пятикратным запасом.

Если у вас проблема именно с mysql, можете попробовать обратиться в percona, они там собаку съели на ней.

дизайн nfs таков, что данные в nfs не кешируются, это факт. другое дело, что при достаточно хорошей сети и NAS этот факт можно попробовать игнорировать.

ну и nfs4 по-моему какой-то там кеш все же есть.

Есть еще весь стек windows networking и CIFS :)

netwind добавил 30.09.2011 в 15:47

Александр Фролов, вот какой план :

попробуйте скопировать все свои файлы на отдельную виртуальную машину, настройте NFS обязательно 4 версии, на актуальных версиях linux ядра, а не том что там у вас.

Погоняйте и померьте реальный трафик NFS. Пойдет даже просто число байт в счетчиках на интерфейсах, хотя лучше мониторинг в динамике.

Таким образом узнаете сколько при генерации обычной странички образуется операций NFS.

Наверняка у вас магазин разделен на части и можно какую-нибудь одну некритичную часть перетащить на NFS и посмотреть что будет. ( Тут еще неизвестно насколько плохо на вечно отстающей freebsd сделан NFS-клиент)

А дальше уже сделаете вывод стоит ли вам покупать NAS.