Попробую предположить, что могло произойти.
Изначально, тестирование облака происходило на 3-5 серверах, и все работало нормально.
Потом, оно стало разрастаться и в какой то момент, уперлось в размер одного коммутатора.
Поскольку 1G, для организации облака уже не достаточно, то внутренняя сеть собиралась на 10G. Недорогие (до 1 миллиона рублей), коммутаторы 10G бывают только до 40-48 портов.
Коммутационной матрицы такого свитча вполне хватит для работы такого мини-облака.
Это будет работать, пока вы не решите выйти на за пределы одного коммутатора.
Потом, нужно подключать второй к первому, их, нужно как-то линковать друг с другом.
Выделяем для этого, 1 из портов 10G на каждом коммутаторе и начинаем забивать вторую стойку.
В какой-то момент, когда во второй стойке набирается критическая масса серверов и линк 10G забивается в полку, получаем рассинхронизацию ceph и ловим, что то типа splitbrain. Даже двух линков по 10G, может не хватить.
По нормальному, коммутаторы 10G должны иметь 2-4 аплинка 40G или 1 линк на 100G которые собираются в агрегирующую ферму размером с холодильник и имеющую на борту вагончик линков 40-100G. Думаю, не нужно объяснять сколько будет стоить такая железка. Да и коммутаторы с аплинками на 40-100G это будут сильно за 1 лям стоить.
Таким образом, правильней, мышам было бы собирать несколько маленьких тучек размером с одну стойку, которые работали бы независимо. В этом случае, с их ценами, еще можно было бы, хоть как-то, выйти на рентабельность. Но, судя по всему, проект не учитывал этот момент роста и панель не была рассчитана на работу с несколькими мини-облаками.
А необходимость агрегации стоек по высокоскоростным аплинкам, в разы удорожает себестоимость системы. По скольку, таких агрегаторов должно быть два и каждая стойка должна агрегироваться в каждый из них, а агрегаторы должны иметь резервные линки друг с другом настроенные по STP.
В идеале, облако должно полностью резервироваться в другом ДЦ.
Плюс, резервное копирование на отдельное СХД. Которое никак не связанно с облаком.
Также, если мы хотим получить полную отдачу от SSD дисков, скорость сети должна быть никак не меньше скорости работы шины сервера. Получается, минимум 2 порта по 10G на 1U сервер с 4 дисками (1 SSD - 500 Мбайт/с = 4Гбит/с * 4 SSD = 16 Гбит/с). В 48-портовый коммутатор можно воткнуть только 24 1U сервера.
--------------------------
Итог, собрать качественное облако в сегменте лоукост, практически, не реально. Или это будет дорого или будет много точек отказа и отсутствие возможности серьезного масштабирования.
Отсутствие проработки масштабирования на этапе проектирования привело к фатальным последствиям. Просто не подумали, какого объема может достичь внутренний трафик при росте количества серверов. Хотя, нужно было просто умножить 16G на количество планируемых в облаке серверов. Думаю, забыли посчитать множитель. Нужно еще учесть, что при ceph, каждый блок данных, хранится в трех местах, соответственно, операции записи утраивают внутрисетевой трафик. Любое облако имеет конечный размер и этот размер должен быть учтен на этапе проектирования. Да, облако можно расширять, но этапы расширения, тоже должны быть заложены в проект.
Все выше написанное, мое ИМХО. Я сделал его, на основе косвенных и обрывочных сведений о характере произошедших фейлов и времени, в которое они произошли. Могу в чем то ошибаться. Но основываясь на своем опыте, смею предположить, что верно угадал причины фейлов.
Надеюсь, если мыши будут делать ребрендинг, они учтут все это и будут собирать более отказоустойчивое облако, однако, сохранение ценовой политики на прежнем уровне, в данном случае, видится маловероятным.
Подняли уже.
Пришлите их отбойки в тикет. Вам еще выделенный IP не перенесли.
Да, не самый популярный, но запросы от клиентов были, по этому мы его и сделали.
У нас по статистике, палкой оплачивают 7.5% платежей.
Мы в свое время вот такими корпусами баловались: http://www.citilink.ru/catalog/computers_and_notebooks/parts/cases/537932/
Их в 45U стойку влезает 16 штук. Наиболее компактное решение из всех, куда можно было запихать полноценные ATX-платы. Единственное, нужно подбирать низкопрофильный куллер на проц.
antipodeman, Осилим, на новом ISPmanager.
Или попросите тех. поддержку перекинуть аккаунт на новый сервер cPanel. Там, нет таких проблем с почтой.---------- Добавлено 05.03.2015 в 17:28 ----------
Выбирайте в платежах Робокассу (ROBOXChange), там куча всевозможных видов платежей, в том числе и Банковские карты. Также, ЯД и PayPal позволяют оплачивать картами.
Написать плагин)?
Да, но она несовместимая с ISPmanager.
antipodeman, Спасибо за откровенный отзыв.
Тут, что называется, нога попала в колесо. Иногда, такое происходит.
Начну с конца, VDS, это то наше направление, которое активно развивается и в него вкладываются большие усилия и ресурсы. И основная масса положительных отзывов именно про этот вид услуг.
Шаред-хостинг, в некотором роде, немного устарел и его пора обновлять, этим мы и занялись активно в конце февраля. Сейчас ввели два новых сервера на cPanel, на которых постарались устранить все ошибки прошлой реинкарнации. На очереди, новый кластер на ISPmanager. В течение этого месяца, планируем сформировать отдел, который будет заниматься именно шаред-хостингом.
Наверное, я поторопился, обновив линейку тарифов, существующая инфраструктура оказалась не совсем готова к ним. Но получалось, что старая линейка тарифов шла в разрез с новыми тарифами VDS. Возникал, достаточно сильный диссонанс. А бурный рост VDS-направления заставил сконцентрировать усилия, именно, на нем.
Масла в огонь подливают, периодические сюрпризы, преподносимые панелями семейства ISPsystem (из-за одного из них, и не работала автоматическая передача Ваших доменов на наши DNS-сервера, этот сюрприз мы словили, аккурат, в момент Вашей регистрации, в ночь с 27 на 28 февраля).
Все, что я написал выше, написано, скорее, не для оправдания, а для понимания, что шаред-хостинг и VDS, это две совершенно разные услуги. Да, их связывает расположение в одном ДЦ и использование такого же железа. Но программная реализация, требует абсолютно разного подхода в организации этих двух услуг. Все описанные вами проблемы, имеют отношение, именно, к программной части, а не к аппаратной.
Над программной частью, работаем, в том числе и путем замены ключевых компонентов на свои. Вот сейчас, на против меня, сидит наш ведущий программист и ваяет заменитель DNSmanager-а, который доставил нам много хлопот в минувшие выходные.---------- Добавлено 04.03.2015 в 01:55 ----------
Распоряжения отдал, ребята сделают перенос данных в ближайшие часы. После переезда сделаем перерасчет.---------- Добавлено 04.03.2015 в 02:03 ----------Ну вроде всем ответил ))) ни кого, вроде, не забыл. На сим, на сегодня откланиваюсь ).
Любые тесты, могут дать лишь приблизительную оценку производительности. Иногда, тесты могут сильно отличаться от реалий.---------- Добавлено 04.03.2015 в 00:57 ----------
Пока, у нас мини ДЦ, но зато эти ДЦ работают. А в Оверсане можно в футбол играть. Всего треть площади под стойками. Из которых половина заполнена выключенными серверами почившего scalaxy, которые так и не сняли. Давайте, Вы найдете денег, сделаете аналогичный проект, тогда и будете смеяться, если сил останется. А то, извините, мне тоже смешно становится, когда ко мне подкатываются с заявлениями: "Покажите мне ЦОД на 20 гВт энергии и сертифицированный по Tier VIII+, тогда я арендую у вас виртуалку за 200 рублей". Мощности адекватны тем ресурсам, которые имеются. Когда имеющиеся ресурсы подходят к концу, в строй вводятся новые. Инвестировать миллиарды в ЦОД, который будет стоять 10 лет пустой, никто не будет.---------- Добавлено 04.03.2015 в 01:04 ----------
Есть такие задачи, которые как не раскидывай, все равно все IOPS-ы сожрут, даже если им целиком дедик отдать, так что, где тут оверсел? Для таких вариантов, у нас есть SSD.
А админы, и так, постоянно занимаются поиском новых решений и оптимизацией старых.
Да, может и правда сделать расписание для дебатов )). А то вот приходится сидеть отвечать на все накопившиеся посты. И это при том, что за последние двое суток удалось поспать всего 1 час, а сегодня еще пришлось мотаться по всей Москве по разным делам. И вот думал уже поехать домой поспать, но пришлось себя заставить отвечать на накопившиеся посты, зная, что многим недостает терпения и постов будет еще больше ;)---------- Добавлено 03.03.2015 в 22:53 ----------
Читайте внимательней.---------- Добавлено 03.03.2015 в 22:54 ----------
Вы уточняйте, что это за два сайта ).---------- Добавлено 03.03.2015 в 23:01 ----------
Предлагаю условится ), что это аббревиатура от Интернет ХОстинг Россия, а чтобы название было более легким и позитивным, то читать его полагается, как Айхор.---------- Добавлено 03.03.2015 в 23:11 ----------
Что я могу сказать, нужны еще тесты, на которые понадобится еще время. Данная конфигурация дисковой подсистемы показала очень хорошие скорости чтения записи на одном типе задач, по этому, решили попробовать ее внедрить на VDS. Возможно такой эффект, дает то, что гипервизор работает на Ubuntu, а не на Centos, где это дало хорошие результаты. Новый кластер будет уже собираться на Centos.
В данной ситуации, могу предложить два варианта, отмигрировтать обратно на старый вариант ноды, где показатели были лучше. Перенести Вашу VDS на SSD.
Также, хочу заметить, что тест с помощью dd, это тест, исключительно, на запись. Если, Ваш проект, действительно, требует много записи, лучше использовать SSD, к тому же, разница в цене у нас не большая.---------- Добавлено 03.03.2015 в 23:27 ----------
Простите, конечно, но мне уже начитает казаться, что у Вас, какая то мания оверсела. На сколько я помню, в Вашей ветке, Вас тоже троллили на эту тему и Вы били себя пяткой в грудь доказывая, что это не так. Мне сейчас совершенно не интересно, бить себя лопаткой в нос и доказывать, что мы не оверселлим. Имеет место быть трабл с производительностью дисковой подсистемы на кластере KVM HDD (причем, не на всех нодах) и мы его решаем. А при чем тут оверселл, я не понимаю. Нода, на которую переехал tlk, в настоящий момент заполнена на 2/3 без и оверселл на на ней, в Вашем понимании, равен нулю.
А вообще, оверселить можно все что угодно и где угодно. В Москве оверселят асфальт мешая его напополам с песком, транспортные компании оверселят автобусы, в час пик, РЖД - эликтрички. Провайдеры - интернет каналы. Даже телефонные операторы оверселят количество подключенных абонентских устройств в отношении к имеющимся потокам E1, понимая, что никогда не будут разговаривать 100% абонентов в одно и тоже время.---------- Добавлено 03.03.2015 в 23:30 ----------
Так а сколько Вы хотите выжать IOPS-ов из HDD? Для HDD, 200 IOPS, вполне нормальное значение.---------- Добавлено 03.03.2015 в 23:38 ----------
Человек регит домены и размещает на них ту инфу, которая отражает его ИМХО. Доверять ей или нет, личное дело каждого. Я бы, вообще, посоветовал всем, проверять всю имеющуюся в современном Инете инфу на достоверность. Верить и Знать - абсолютно разные вещи. У на то, что он регит домены на несуществующие данные. Так таких сейчас много. Со всеми дело не иметь?
