C нуля можно начать и имея $100. Не работайте в гос. структуре, откажитесь от покупок бестолкового железа, бестолковых бухгалетеров, прочих бюрократических геморроев и планка "входа" резко упадет. Свои сотрудники также в начале не нужны. Просто арендуйте выделенный сервер с сопровождением у уже существующего хостинг-провайдера, заплатите разовую сумму за настройку биллинг панели и консультацию или разберитесь с этим самостоятельно и все. Можно работать, если конечно есть понимание того, зачем.
Если цель в заработке средств - не выйдет ничего хорошего. Если цель в том, чтоб предоставлять качественный сервис и интересна просто эта тема, то шансы на успех огромны.
ТС, не обижайтесь, но это идиотизм, тратить 300 000 в то, в чем не разбираетесь и разобраться не хотите, а по Вашему сообщению сложилось такое впечателение. Лучше купите Range Rover Autobiography еще один, как раз впишитесь в бюджет с учетом длинной базы и доп. наворотов, больше радости моральной получите :)
Приветствую!
Нидерланды (Switch) / 2 x Intel Hexa-Core Xeon L5640 / 128GB RAM / 2x480GB SSD / 1 Gbps 100TB - $511.01 к оплате
Оформить заказ возможно из конфигуратора на сайте: http://www.ua-hosting.company/servers
Трафик и канал можно добавлять по мере необходимости в любой момент.
Так как большинство наших клиентов (а порой даже и наших коллег по цеху) далеко не всегда понимают, какими факторами нужно руководствоваться при подборе выделенного сервера клиенту, для обеспечения должной производительности хранилища, я написал очень полезную статью:
https://habrahabr.ru/company/ua-hosting/blog/282469/
Критику, отзывы, буду рад увидеть в комментариях.
Gedag вообще задал вопрос клиенту о сервисе, на котором он обслуживается. Что же касается выделенных серверов - то в случае выделенного сервера, аптайм также зависит от квалификации тех. поддержки провайдера в большинстве случаев, а не только от того, насколько хороша сеть в дата-центре.
К слову сказать, мы принимаем участие и в мониторинге сети дата-центра. Так как некоторые из наших клиентов на мониторинге, мы по сути мониторим в том числе качество работы сети в различных ее точках. И были случаи, когда наш тех. отдел обращался в тех. отдел дата-центра, что где-то случилась деградация канала, либо трафик не выдавался в полку (потерь еще нет, но профиль показывает, что уже закончилась емкость канала у роутера из шкафа).
Были также случаи, когда падал какой-то из аплинков и мы просили дата-центр отключить проблемный PNI на это время по этой причине и отправить трафик по другому маршруту. Также, как и случаи, когда вне дата-центра были проблемы и нужно было перероутить трафик.
Да, наш тех отдел физически не способен устранить эти проблемы, без инженеров дата-центра. Но диагностические данные важны и нередко мы их предоставляли.
Это сейчас атака на "соседа" в стойке заметна практически сразу, а ранее - мы просто фиксировали потери у нас (последствия для нас) и уведомляли об этом ЦОД.
Вы наверное удивитесь, на большинство грамотно выполненных отказоустойчивых проектов, которые не требует десятигигабитных прямых линков между серверами баз данных (у нас был и такой опыт), прекрасно может работать на серверах в общих стойках. И правильно настроить такую систему - большой труд.
И надежность этого решения будет выше, нежели разместить серверы в двух приватных шкафах, с описанным Вами резервированием.
По поводу Private VLAN, о котором Вы писали выше - мы в курсе, вот только он не работает, как нужно, так как порой клиенту нужно использовать все выделенные ай пи адреса в его среде, а в LSW они привязаны к конкретным шкафам. Не говоря уже о том, что за него хотят дополнительных денег.
У такой конфигурации будет расти latency при активной записи и, как следствие, падать количество IOPS на запись, причем возможно катастрофически. Если уж использовать исключительно SSD - целесообразнее использовать диски меньшего объема в массиве и в большем количестве. Но тут будем также упираться в latency самого медленного из дисков.
Если Вы считаете, что серверы с 1000+ клиентов (в данном случае хостинг-ноды), работают сами по себе и их не нужно сопровождать (отслеживать работу сервисов, нагрузку, различные сбои исполнения скриптов, решать вопросы с безопасностью), то есть по Вашему их можно просто поставить в дата-центр и не трогать, то говорить с Вами далее не о чем.
Дать нормальный канал, к серверу, извините, как раз таки небольшого ума дело. Достаточно раз сделать нормальную топологию сети.
А что меняется в случае того, когда "берется стойка"? Какие тогда заслуги у провайдера? Арендовать стойку - также не большого ума дело. У нас в Украине было 2 шкафа со своим оборудованием и свои ротутеры и свитчи, и что?
К слову сказать, свои свитчи у нас есть и в LeaseWeb (к примеру в США, для одного из клиентов - нам это понадобилось).
Как Вы сказали - сделали один раз сеть, подключили все и работает. Заслуг дата-центра больших в этом нет.
А вот сопровождать высоконагрузочные проекты, уметь балансировать нагрузку, оперативно решать большую часть проблем еще до того, как они будут замечены клиентами - совсем иное дело.
Если бы все было так просто - дата-центры не искали бы партенров, а продавали услуги сами. А сейчас первая линия поддержки ложится как раз на провайдера и провайдер выполняет основную работу.---------- Добавлено 23.04.2016 в 14:26 ----------
Услуга мониторинга предоставляется у нас по цене от $10 / месяц (50% скидка при заказе услуги на постоянной основе).---------- Добавлено 23.04.2016 в 14:40 ----------
Два человека в нашей тех. поддержке были заняты еще какими-то запросами и просто не заметили, что там единицы разные. Вы бы и сами не факт, что обратили внимание. Это Вы так сейчас уверены, что волшебны во всем, а загрузить Вас работой и множеством тикетов - могли бы тоже что-то не заметить. Наши люди на смене пытаются всем быстро дать ответ и максимально оперативно помочь. Причем зачастую оказывают помощь "бонусом", если вопрос не сложный, но знаете сколько таких "не сложных" и "быстрых" вопросов?
Они просто не заметили разности единиц. Преступление? Нет. Тем более, что расхождения случались в учете трафика по вине дата-центра ранее.
Я бы понял какие-либо упреки в адрес нашего тех. отдела, если бы была жалоба вида "мне не отвечали очень долго, этот вопрос можно было решить оперативнее".
Но наш тех. отдел зачастую дает ответы в течении 5-15 минут в любое время суток.
Так что Ваши оценки действий и квалификации тех. поддержки - просто какой-то some shit, растение такое, на русском.
Так Вам VPS на SSD или на HDD нужен?
А то в теме SSD, а в запросе HDD.
Можем сделать в Нидерландах за 3,99 в месяц http://www.ua-hosting.company/vps:
Ядра (vCPU) 1 Core
Память (vRAM) 1 GB
Дисковая квота 40 GB (SSD Storage)
Порт 1000 Mbps
Премиум трафик 4 TB
При условии оплаты услуги на год. Принимаем PayPal.
Возраст: более 7 лет.
Для получения спец. цены откройте тикет в биллинге со ссылкой на эту тему. Вам выставит отдел продаж счет и сможете оплатить PayPal.
А рассчитать не судьба на основе указанных данных? Трафик - не самое важное тут, тут важнее обеспечить производительность системы.
При 3000 хостов в день - получаем примерно до 50 пользователей онлайн в пиковые часы, в соответствии с среднесуточной кривой посещаемости для подобного рода ресурсов. Точнее можно сказать, посмотрев на статистику непосредственно.
Если 3000 человек в день качают файл (максимум 10 мегабайт, берем худший сценарий, понятное дело, что не все качают, но некоторые пользователи могут качать несколько файлов), то получается, что Вам необходимо обеспечить отдачу трафика в (3000*10*30/1024/1024 = 0,86
ТБ ) минимум 1 ТБ в месяц на исход. Пиковая нагрузка по каналу, когда 50 пользователей онлайн что-то качают на сайте, при условии допустимого времени скачивания файла максимального объема в течении 5 секунд, составляет 50*10*8/5 = 800 мегабит / с (худший сценарий, если все 50 человек запросили одновременно файл максимального объема).
Соответсвенно, для обеспечения быстрой отдачи файлов с хранилища - рекомендован сервер с гигабитным подключением к сети Интернет.
При хранении миллионов файлов с перспективой роста до 50 000 файлов в день и единым хранилищем, не забудьте обратить внимание на inodes, при создании файловой системы. Рекомендуется применить большее количество дисков меньшего объема с целью обеспечения отказоустойчивости массива и более быстрого ребилда RAID.
Применять SSD накопители и CDN для кеша популярных файлов - сейчас нет необходимости, так как основной расход производительности у Вас будет на ЗАПИСЬ (парсинг с других ресусров, нежели на чтение). Пиковая нагрузка чтения спокойно обрабатывается оперативной памятью сервера, 8-16 GB RAM будет вполне достаточно.
А вот запись - ключевая Ваша проблема, тут хранилище нужно рассчитывать исходя из того, какую пиковую нагрузку Вы хотите обеспечить на запись одновременно. Если Вы хотите спарсить все и записать в течении часа - это один разговор, если все будет более-менее распределено во времени - совершенно другой.
Предположим, что средний размер контента объявлений - 3 МБ и Вы парсите их равномерно в течении 12 часов, так как большую часть объявлений публикуют в дневной период, а не ночной все же.
Рассчитаем необходимый трафик 3*30000*30/1024/1024 = 2,57 ТБ на вход в месяц.
Вероятнее всего, что Вы не будете синхронизовать конетнт с другими сайтами, посредством онлайн-синхронизации, так как придется держать открытыми множество соединений, что приведет к неэффективному использованию оперативной памяти (от 64 КБ на установку каждого соединения, а если сайтов тысячи, то и 16ГБ оперативной памяти будет мало).
Допустим, что Вы будете парсить контент раз в 10 минут в течении 1 минуты (время исполнения скрипта), таким образом в течении 1 минуты Вам необходимо будет спарсить 3*30000/12/6 = 1 250 МБ данных, что предъявляет требования к каналу 1250/60*8 = 166,67 Мбит / с .
Один HDD SATA накопитель обеспечивает в пределах 50-75 IOPS (операций ввода вывода в секунду).
Если мы возьмем 12 накопителей и соберем их в RAID10, то мы получим производительность записи в пределах 450 IOPS в лучшем случае, в то время, как на чтение - до 900 IOPS.
В итоге за одну операцию ввода нам нужно будет передавать 166,67/8*1024/450 = 47,41 КБ данных и чтоб уложится в наши 450 IOPS лучше будет выбрать размер кластера (блока) 64 КБ, а с учетом того, что нам нужно еще и отдавать трафик, пусть и с кеша в оперативной памяти, 128 КБ. Однако, следует помнить, чтоб при росте размера кластера, производительность в IOPS накопителя имеет свойство снижаться.
Помимо прочего, при наличии на сервере операций чтения / записи одновременно, снижается общая производительность накопителя.
Потому, я бы рекомендовал, либо, парсить контент настолько равномерно, насколько это возможно, либо использовать дополнительный SSD-накопитель для кеша и парсинга.
Однако однозначно, с целью обеспечения максимального значения IOPS, лучше брать сервер с большим количеством дисков меньшего объема, нежели сервер с меньшим количеством дисков большего объема.
Вывод:
12 дисков в RAID10 - это минимум то, что Вам необходимо для комфортной работы, возможно следует использовать SAS, а не SATA.
Либо меньшее количество + SSD для парсинга и возможно популярных файлов, либо большее количество RAM в сервере в зависимости от требований.
Подключение - 1 Гбит / с, лимит трафика от 10 ТБ в месяц.
Для отказоустойчивости можно создать кластер из 2-х таких серверов.
Приветствую, прежде всего нужно рассчитать необходимую производительность сторедж-системы, одной из приблизительных метрик, является измерение в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения). Но нужно помнить, что она подвержена влиянию большого множества факторов.
Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в конкретных случаях. И это значение зависит далеко не только от накопителей, которые используются, но и от уровня RAID, размера кластера (блока) файловой системы, а также от характера нагрузки. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I / O). Таким образом, системы хранения, которые, на первый взгляд, должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.
Уточните сколько изображений / видеофайлов будет хранится, будут ли проходить процессы конвертации, какую производительность нужно обеспечивать на скачивание (сколько файлов качают одновременно, средний размер файлов, сколько популярных файлов, нужно ли обеспечить возможность стримминга - просмотра видеофайлов онлайн).
Максимальный аптайм?
Это что в Вашем понимании. От этого зависит, насколько распределенную систему резервирования необходимо делать.
Ну и огласите Ваш бюджет и текущую посещаемость проекта.
Если проект новый и пока только в разработке - возьмите для начала что-то вроде 2 x Intel Quad Core Xeon E5504 16GB DDR3 6 x 2TB SATA 1Gbps 100TB, и сделайте проект масштабируемым, чтоб можно было добавлять впоследствии новые ноды и обеспечивать должную нагрузку.
На серверах с HDD SATA накопителями - исключительно RAID1+0.
Если будут вопросы - обращайтесь, проконсультируем, в зависимости от входящих параметров, порекомендуем с каким размером блока сделать файловую систему и как лучше организовать отдачу.
Бюджет решения - от $100 / месяц до .... в зависимости от требований Вашего проекта и локации. Если Россия - будьте готовы платить за железо и трафик дороже, а также решать проблемы с местными правоохранителями.
Если Нидерланды - будет дешевле, есть прямая связность с РФ из Европы, плюс Вы обретете меньше проблем с российским законодательством, так как если люди зальют видео для взрослых - это чревато изыманием сервера в РФ и расследованием.
А ничего, что речь идет об услуге хостинга, где ноды у нас имеют тысячи клиентов и где аптайм определяется далеко не стабильностью сети дата-центра, а по сути исключительно навыками администрирования подобных систем?
Помимо прочего, в случае тех же выделенных серверов, на показатель аптайма влияет скорость реакции нашей тех. поддержки, а также их уровень опыта. Более 90% всех проблем на выделенных серверах зачастую никак не связаны с работой сети дата-центра или работой железа.
И если человек с выделенным сервером сопровождается у нас, наш тех. отдел делает все, чтоб его сервер был онлайн, принимает все возможные привентивные меры, чтоб избежать недоступности из-за программной проблемы (упал какой-то сервис) или же из-за проблемы с железом (заранее проводятся тесты и комплектующая подлежит заблаговременной замене).
Так что Вам уместно было бы извинится, ведь Вы даже не наш клиент и по сути ничего не знаете о качестве технической поддержки, которую предоставляют наши сотрудники. А Вы незаслуженно очернили их работу.
Почему-то полагая, что заслуга аптайма всегда лежит на дата-центре, хотя, на самом деле, это только 10% составляющей, а у нас, с целью обеспечения стабильности и качества, трудится свыше десятка человек.
К слову сказать, в LSW были случаи, когда их инженеры "втыкали" и к шкафам заканчивалась capacity, возникали потери на канале в определенном шкафу у части абонентов, и еще до того, как клиенты ощущали это, наш отдел мониторинга писал тикет в дата-центр. Так что заслуга стабильной сети - не только на инженерах дата-центра.---------- Добавлено 22.04.2016 в 11:35 ----------
Дошло до маразма. Конкуренция не дает Вам покоя. Я понимаю, что мы, пожалуй, самый активный тут провайдер по показателям роста, но хотя бы пишите логичные вещи и упускайте подобные алогичные высказывания. Если все, что выше, о том, какая услуга и т.п. - логично, то последнее это просто :facepalm: .
Но стоит отдать Вам должное, что Вы, в отличии от lsw_fan, хотя бы не очернили работу людей и действительно задумались, о каком же сервисе идет речь. Спасибо.
