fc.ru, предложения в личку
http://jet9.ru , выбираете Отказоустойчивый кластер с репликацией, с двумя и тремя узлами. Ответственность определяется выбранным SLA.
Quickaurum уже наш новый проект http://jet9.ru упоминал, я вот его под эту задачу в явном виде предлагаю. Внутри там аналогично обычному шаред-хостинг, то есть поддерживаемый и обновляемый нами. Первый вариант такой реализации я запускал в Net.ru в 2007, но без HA, CDN и контейнеров.
В jet9 сделано разделение по ресурсам и тарификация как у VPS, так как он предназначен для сайтов с достаточно высокими нагрузками и без изоляции по ресурсам здесь не обойтись. У каждого пользователя там собственный apache и mysqld, поэтому соединений будет столько, сколько нужно. На счет ответственности и штрафных санкций - определяется выбранным уровнем SLA. Глубина вникания тех. поддержки в проблемы - тоже определяется выбранным в заказе уровнем .
Единственный непонятный в требованиях момент - про 2 IP. Формально, вместе с фронтендами CDN, в российском сегменте будет от 6 до 250 адресов. Но может быть имеются в виду выделенные IP только под ваш сайт?
Про то, чтобы все 100 работали ТС не писал. А зачем ему вообще много соединений - это не существенно.
Какой-то пессимистично настроенный калькулятор, он считает, что все соединения будут постоянно одновременно выполнять запросы, заполняющие все их буферы. Тогда тысяча активных запросов - это тысяча активных тредов в mysql, нагружающих диск и процессор. Нерационально. Тут не только 181 Gb памяти будет нужно, но и 181 процессорных ядер.
На практике большинство соединений находятся в неактивном режиме в пустыми буферами и реально при этом расходуется - стек треда, 128 Кб. Почему могут быть в неактивном - одни из-за приложения с персистентными соединения, другие приняли запрос и ждут, когда разблокируется какой-то ресурс, третьи выполнили запрос и уе освободив буферы продолжают отдавать данные в приложения, четвертые обслуживают фоновые процессы. У нас техотдел клиенту тюнил сервер, где несколько сотен долгоживущих процессов держат соединения с базой и обмениваются данными через таблицу в пол мегабайта. Лимит на число соедиений там, думаю, около 500.
Вероятно, все хранилось в одном пуле ceph и потерялись его мета-данные. Основная причина потери метаданных в современных версиях - апгрейд версии ceph. Но для старых версий бывали случаи, когда мета-данные терялись либо в результате изменения конфигурации хранилища, или "сами по себе" при цепочке отказов оборудования. Хотя может быть тут и новый баг нашли. В трекере ничего похожего пока не видно, но, надеюсь, в этом случае cloudmouse напишут разработчикам багрепорт.
У вас на какой версии это случилось? Вы в Inktank по проблеме обращались или они не стали участвовать в диагностике?
Если у вас аварийное хранилище еще осталось в прежнем состоянии, мы можем попробовать помочь восстановить данные. У нас тоже в одном проекте строится и обкатывается большое хранилище.
Спасибо, реально хороший вариант.
А наращивание - имеете в виду, что можно будет поочередно менять диски на большей емкости? Или не все 24 сразу брать и потом доставлять?
Трафик небольшой, в среднем получается на каждый 1Тб хранения около 400 Гб в месяц.---------- Добавлено 11.06.2014 в 17:20 ----------
Не, там достаточно бесполезная придумка. Никому не нужно, не взлетит.
Да, это реально из самых дешевых, тоже есть. Но нужны еще альтернативы :) Не всех клиентов хецнер устраивает. И яйца должны быть рассредоточены.---------- Добавлено 11.06.2014 в 15:58 ----------
Коло - это понятно. Но с этим есть неудобство - нужно будет сразу закупить несколько дорогостоящих дисковых полок и они достаточно долго будут почти пустыми. Плюс еще нужно минимизировать наше участие в процессе, а предлагать клиентам самим ставить диски и разрешать им копаться в чужом железе - совсем не вариант.
Т.е. нужен все-таки сервис. Не нужно вообще самое дешевое, просто амазон с ракспейсом - это для сервиса реально дорого.---------- Добавлено 11.06.2014 в 16:00 ----------
Ну все-таки не впсок :) Там стоимость диска самая высокая.
Ну да, перечитал сейчас первый пост - сам не понял, что хотел :)
Интересует не CDN, а приватное хранение. Одна часть - это бэкапы, с редким чтением и периодическим обновлением. Вторая - активно используемые данные. Что-то ближе к Amazon EBS и Glacier, Rackspace cloud files (они уже используются). Нужно еще другое, желательно в России, и не такое дорогое как Amazon и Rackspace. Объемы - от нескольких Тб до нескольких десятков Тб.
Dropbox и прочие - это совсем другой профиль.
Обновил еще пост топика.
