Мы не совсем провайдеры, мы предоставляем сервис интернет-магазинов, и у нас такая политика относительно тех, кто забывает или не успевает внести ежемесячную плату:
- когда платеж просрочен, автоматически блокируется управляющий сайт. При этом сайт витрины магазина продолжает работать, на нем можно продолжать покупать товары;
- при автоматическом блокировании управляющего сайта у пользователя есть возможность продлить его работу через личный кабинет на 10 дней. Таким образом, можно сразу включить управляющий сайт, а потом внести оплату;
- если оплата не вносится больше месяца или систематически, мы можем отключить витрину сайта, однако перед этим можем связаться с клиентом по почте или телефону.
Таким образом, у забывчивых клиентов не отключается сайт витрины, не пропадают деньги, вложенные в рекламу сайта, и не теряются заказы. С другой стороны, отключение управляющего сайта и наличие 10-дневного срока для его работы без оплаты стимулирует внести оплату как можно быстрее.
Что же касается окончательного удаления сайта с сервера, то мы это делаем обычно в тех случаях, когда сайт закрыт уже несколько месяцев. Часто бывает так, что клиенты возвращаются, и в этом случае мы можем включить им магазин очень быстро.
Окончательного удаления сайтов не происходит, т.к. все остается в долгосрочных бекапах. Конечно, восстановление из бекапов -довольно медленная процедура, но это для нас все же проще, чем открывать сайт заново.
В этом смысле я поддерживаю satbauer, т.к. часто лояльное отношение к клиентам себя оправдывает.
По моему мнению, виртуальный хостинг - это решение для бедных, а VDS - решение для жадных :)
Бедные, как известно, не выбирают, а жадные - платят дважды (если не трижды). Впрочем, как промежуточный этап для перехода к физическому серверу и для экспериментов VDS вполне пригоден.
Если Ваш проект приносит мало прибыли и $50 в месяц для Вас - большие деньги, нет никакой альтернативы виртуальному хостингу. Вы можете переносить свой сайт с хостинга на хостинг, но везде будут ограничения, которые Вы не сможете контролировать, как это Вам тут уже объяснили.
Можете просто забыть о том, чтобы полностью контролировать пользование ресурсами на виртуальном хостинге и реально действующие ограничения - так устроен виртуальный хостинг. Если Вам нужен такой контроль, пользуйтесь выделенным физическим сервером. Если нет денег на сервер, просто пользуйтесь тем, на что у Вас есть деньги - все равно никакого другого варианта нет.
Вариант с VDS тоже не поможет, т.к. там одна дисковая система используется многими виртуальными машинами, и она может быть перегружена. Кроме того, память на VDS стоит дорого, и администрирование тоже дорогое.
Если речь идет о повышении надежности, то на мой взгляд, путь здесь один - взять в аренду физический сервер или купить свой, тогда может идти речь о каких-то гарантиях. А если Вы просто хотите наказать провайдера за то, что он, по Вашему мнению, недодает Вам каких-то ресурсов, то это бесполезный путь, на котором Вас ждут только эмоциональные и финансовые потери.
Более позитивно думать о том, как поднять доходность своего проекта, и тогда появятся средства для увеличения надежности его работы.
Программа R-Studio умеет восстанавливать данные из разных файловых систем, в том числе и ext3(4). Она работает с диском на уровне чтения секторов, диск с восстанавливаемыми данными, разумеется, не монтируется в Windows. Хотя сама R-Studio предназначена для работы в среде Windows.
Насчет посекторного бекапа - R-Studio умеет это делать. Такой бекап не повредит, конечно, однако если диск хороший, без битых секторов, то делать бекап не обязательно. R-Studio обращается к диску только в режиме чтения.
Попробуйте R-Studio. Диск надо вытащить из сервера и подключить к ПК с Windows.
Сейчас мы пишем систему нагрузочного тестирования для нашего приложения, но это не будет быстро. По загруженности ресурсов сервера вся информация есть, но проблема в том, что у кластера будет другая архитектура, и нам не с чем сравнивать...
По поводу percona да, 5 числа в Москве будет семинар Петра Зайцева по MySQL, мы командировали туда нашего специалиста. Надеюсь, этот семинар прояснит вопросы кластеризации MySQL.
Александр Фролов добавил 30.09.2011 в 16:18
Вообще я столько всего плохого про NFS начитался, что пробовать как-то не хочется)
Тем более что эксперименты будут довольно дорогостоящими. Тут хотелось бы получить готовое, отлаженное решение, проверенное на проектах подобного уровня.
Решение ISP Manager Cluster создавалось, насколько я понимаю, для массового хостинга относительно малонагруженных проектов. По архитектуре действительно нам подходит с оговоркой про NFS, и с дополнениями в виде кластеров MongoDB и Spninx.
Наш поставщик серверов вообще занимается кластерами, правда, немного не такой направленности как наша. По стоимости, насколько я понял, система хранения данных нужного нам объема будет стоить примерно как два-три хороших сервера. Так что если есть возможность сделать более надежное решение на оптике, это мне больше нравится.
Еще есть решение на блейдах, но тут меня настораживает строгая привязанность к одному производителю и потенциальные проблемы при обновлении железа в будущем.
А насчет возможности совместного использования файловой системы СХД я спрошу у поставщика при случае. Но насколько я понял, они мне как раз и рекомендовали такую систему для моего кластерного решения.
Идет огромное количество обращений к файлам с стороны витрины интернет-магазина и бекофиса. Сейчас все эти файлы лежат в кеше операционной системы в оперативной памяти, и быстро туда попадают с локального диска. А так будет задействован сетевой стек. Вообще я читал где-то на форумах отзывы о том, что начинаются тормоза в ISP Cluster, связанные именно с NFS. Точно не могу вспомнить, где читал.
Нагрузка будет только расти со временем, поэтому хотелось бы избавиться от потенциально узких мест.
Вот тут, если можно, поподробнее. Как тогда работают подобные кластеры с общим дисковым хранилищем?
Да, в договоре будут пункты о конфиденциальности, однако я вначале должен понять, что мне предлагают и узнать цены на все, а потом уже заключать договоры и предоставлять информацию.
Насколько я понимаю, состава системных сервисов и схемы их взаимодействия должно быть достаточно для подбора архитектуры кластера. А логика работы приложения - обычная логика интернет-магазина, ERP и CRM. Есть клиенты, заказы, товары, документы и еще несколько сотен сущностей, сотни таблиц базы данных и сотни классов. Описание всего этого в деталях - отдельная и очень сложная работа. Поэтому надо как-то сделать первоначальную оценку без детальной информации.
По моему представлению на сегодняшний день, после балансировщика должен идти кластер из двух-трех серверов, на которых будет апач и скрипты приложения. Эти серверы будут подключены через оптику к общему хранилищу данных. Еще пара серверов нужна для кластера MySQL (плюс управляющие серверы), аналогично для MongoDB. Memcached можно, видимо, запускать на тех серверах, где будет работать приложение, а Sphinx - где MySQL или на отдельных серверах.
Такая или почти такая архитектура предлагается и ISP Manager Cluster (в основе), только там нет общего хранилища, подключенного по оптике, а есть медленное хранилище NFS. Вот это хранилище меня и смущает в их предложении - не подойдет для высокой нагрузки.
Если у нас будет подобная архитектура кластера, мы сможем самостоятельно справиться с настройкой приложения, чтобы оно обращалось за нужными сервисами к нужным хостам. Установка кластера с балансировщиком на Linux, насколько я понимаю, не очень сложная задача и у меня есть предложения от людей, готовых сделать это. И по железу - поставщик, у которого мы обычно покупаем серверы, готов предложить нам все железо для кластеров и настроить балансировщик и кластер на RedHat или Scientific Linux.
Наибольшие проблемы мне представляются с кластером MySQL, т.к. видимо придется вносить изменения в приложение, чтобы учитывать особенности работы MySQL в режиме репликации. Но это мы сможем отладить на виртуалках.
На данном этапе мне нужно подобрать архитектуру кластера и решение, найти тех, кто сможет сконфигурировать системные средства, понять, во что все это обойдется заказчику. А приложение мы будем переносить на кластер уже силами своих программистов. Т.е. конфигурирование системных средств, возможно, мы бы могли отдать на аутсорсинг, а лучше бы выполнили сами по описанию. В теории можно ведь установить самостоятельно ISP Manager Cluster, там есть какая-то инструкция и установщик.
В любом случае мы не сможем предоставить административный доступ к кластеру после установки на него нашего приложения.
В этом плане с точки зрения прозрачности и понятности мне нравится предложение ISP Manager Cluster, но как я уже писал, в стндартной конфигурации у них NFS и с гарантированной реакцией на заявки не очень понятно.
Там все конфиденциально, логику работы описать не сможем, особенно детально. Она, кстати, очень сложная, а внесение изменений очень трудоемкое. Хотелось бы получить решение на системном уровне. Видимо, допускается разнесение сервисов по хостам, но с обеспечением быстродействующего канала передачи данных. Сейчас ведь все в оперативной памяти одного хоста, и работает быстро, а вот если разнестим по хостам - не уверен.
Собственно, помимо чисто аппаратной кластеризации от IBM рассматриваю возможность выделения в кластер сервер приложений, т.е. будет балансировщик, Апач с nginx, отдельно кластер MySQL, отдельно кластер MongoDB и Sphinx.
