В настоящее время мы готовимся к переносу веб-сайта с достаточно высокой посещаемостью в облако.
Мы думаем об использовании scalr, чтобы помочь нам управлять всей настройкой, тем более что у нас нет опыта работы с Amazon.
Мы не уверены в том, следует ли нам использовать функциональность MySQL Scalr, основанную на инстансах EC2, поддерживаемых EBS, или мы должны использовать RDS или даже xeround и получать гораздо более простое обслуживание и управление.
Наш набор данных составляет около 40 ГБ, и мы потребляем 4000 ГБ в месяц между сервером приложений и сервером базы данных.
какой-либо опыт использования подобных установок?
заранее спасибо
Я могу сказать вам по моему опыту с большим db .. но намного больше, чем ваш, около 90 гигов.
Мы использовали RDS, и по крайней мере 3-4 раза в день мы получали ужасную задержку при запросах. Как и запросы, которые занимают секунду, будут выполняться 10-20 секунд. Мы перешли на их самый крупный инстанс, поддерживаемый рейдовой EBS, и производительность была примерно такой же, но мы не достигли этих действительно сильных всплесков задержки.
Переход в облако - действительно очень хороший вариант. Самое сложное в масштабировании облачного приложения - это масштабирование базы данных. Не запутайтесь, у MySQL есть решения для аварийного переключения (сколько времени это займет…), которые могут поддерживать несколько реплик для обработки чтения. Scalr и RDS - очень подходящие варианты, если вы знаете, каковы ограничения… Scalr - они масштабируют вашу БД, предоставляя подчиненные базы данных, ведущие устройства и настраивая репликацию данных. Хотя автоматическое выделение ресурсов упрощает работу, а репликация дает некоторые меры, имейте в виду, что добавление репликации чтения не исправит записи OLTP… и не обеспечит истинную линейную эластичность по требованию. Каждый раз, когда вы добавляете реплику для чтения, это, скорее всего, событие службы.
Для HA Scalr использует EBS. Если последний очень длительный простой AWS EBS является каким-либо признаком ... убедитесь, что ваши данные / хранилище также соответствуют требованиям высокой доступности ...
Масштабируемое решение должно быть линейным и гибким (масштабирование, увеличение, увеличение, уменьшение) по запросу без простоев. Облачным приложениям нужна собственная истинная высокая доступность - несколько реплик, постоянно выполняющих чтение и запись, а не аварийное переключение. RDS подтвердит ту же настройку «предварительно сконфигурированного MySQL» и, следовательно, будет иметь те же ограничения. И последнее, но не менее важное: убедитесь, что нет единой точки отказа и каково влияние на ваших разработчиков ... каждый раз, когда вы вносите изменения в приложение. В Xeround наша цель разработки заключалась в решении этих проблем. Наши гены уровня Telco и решения, разработанные с первого дня как виртуальные для облачных операций, позволяют нам предлагать по запросу, эластичную, супер масштабируемую и высокодоступную облачную базу данных без каких-либо проблем.
Мы провели бета-тестирование, которое длилось год, с тысячами пользователей, многие из которых точно такие же, как вы.
Мы теперь GA - пожалуйста, войдите, чтобы 30 бесплатная пробная версия (кредитная карта не требуется) и убедитесь в этом сами.
Рази Шарир (Xeround).