FirstDedic Хостинг

Меня зовут Лев, я главный администратор сайта объявлений о продаже и аренде недвижимости Onrealt. Хочу поделиться впечатлениями о сотрудничестве с компанией FirstDEDIC.
onrealt.ru



С чего всё началось
Наш сайт — это доска объявлений для поиска недвижимости. В целом, идея не уникальна и конкурентов в данной нише много, но изучив рынок, мы сделали выводы, что конкурировать можно и без большого бюджета, коим мы не обладали.

Проект не подразумевал высокую нагрузку после запуска, но был разработан с учётом возможности масштабирования, чтобы мы могли подстроиться под аудиторию любого размера. Поэтому планировалось построить такую серверную инфраструктуру, которая позволит сэкономить на старте, но при этом предусмотреть возможный рост посещаемости в будущем.

Вариант с приобретением своего железа был отброшен сразу — слишком дорого. Спрогнозировать рост аудитории непросто, как и доход без больших инвестиций. В таких условиях поддержка своей собственной серверной архитектуры попросту нерентабельна, поэтому выбор был сделан в пользу аренды.

Арендуя оборудование, мы не рискуем понести ощутимые финансовые убытки, если проект окажется не востребован. Конечно, мы приложили максимум усилий, чтобы обеспечить успех проекта, но для нас было важно учесть все варианты развития событий.

Как мы выбирали хостера
Перед нами стоял выбор среди множества компаний, предоставляющих услуги аренды оборудования. При выборе мы опирались на следующие критерии.

• Оптимальное соотношение цены и качества.
• Стабильная работа оборудования.
• Возможность выбора гибкой конфигурации серверов, каждый из которых необходим для решения определённых задач.
• Быстрое подключение новых серверов.
• Подключение серверов в локальную сеть.
• Отзывчивая и компетентная техническая поддержка.

Изучив рынок, мы выбрали FirstDEDIC. Конечно, по отзывам сложно удостовериться в том, что компания соответствует всем критериям, но мы решили попробовать и, как выяснилось позже, не ошиблись.

Наша инфраструктура
Изначально мы арендовали 5 серверов. Все серверы были объединены в VLAN (виртуальная локальная сеть) для конечной реализации нашей структуры.


Сервер для работы с базами данных
На данном сервере разместили основные базы данных — MySQL и Memcached для хранения сессий. Чтобы надёжно хранить большой объём данных и быстро с ним работать, мы выбрали следующую конфигурацию: два процессора E5-2620v4 2.1-3.3 ГГц (8 ядер), 256 Гб оперативной памяти, два SSD 1920 Гб в зеркальном рейде.

Сервер для репликации базы данных и бекапов
Основная задача данного сервера — хранение резервной копии базы данных и репликация части таблиц для оптимизации выборок MySQL.

Вкратце, при репликации возможно изменить управляющий механизм хранения базы данных с InnoDB, который отлично подходит для записи большого объёма данных, на MyISAM, который лучше подходит для выборок. Преимущества данного подхода условны и индивидуальны, но требованиям нашей архитектуры БД он отвечает.

Сервер для распределения нагрузки между веб-серверами
Так как была предусмотрена возможность масштабирования, не обошлось без балансировки запросов к веб-серверам. Именно для этих целей был необходим сервер-балансировщик, который будет распределять распределять запросы среди остальных серверов, независимо от их количества.

Основной веб-сервер
Задача данного сервера — обработка входящих запросов к сайту и к API для приложений.

Наша структура позволяет использовать неограниченное количество веб-серверов и гибко подстраиваться под рост и спад аудитории, расходуя оптимальный бюджет. Как только появляется необходимость, мы быстро вводим в стек дополнительный сервер.

Сервер для хранения файлов
Наш сайт содержит множество объявлений, а объявления в свою очередь — много фотографии. В итоге нам необходимо хранить внушительный объём файлов.

По аналогии с веб-серверами, количество серверов для хранения ограничено только нашей потребностью в них — каждый новый сервер встраивается в нашу структуру за считанные часы.

Чего мы добились
Наш сервис был запущен в конце декабря 2017 года, а уже в 2018 году ежемесячная посещаемость выросла до 900 тысяч. В 2019 году — до 1,6 млн, в 2020 уже до 2,4 млн уникальных посетителей в месяц.


Это стало возможно в том числе благодаря тому, что наша серверная инфраструктура предусматривала возможность масштабирования. На протяжении сотрудничества с FirstDEDIC количество арендуемых серверов увеличилось с 5 до 15.

Все наши ожидания были оправданы, оборудование работает стабильно. Если возникают какие-либо проблемы, сотрудники компании сразу сообщают нам об этом — в большинстве случаев еще до того, как мы сами обнаружим проблему.

Мы решали сложную задачу, потратили много сил, достигли неплохих результатов — без надёжного хостера это было бы невозможно.

https://firstdedic.ru

Всегда интересно, как клиент попадает к нам, на основе каких параметров он делает свой выбор — в нашу пользу или в пользу другого провайдера. В последнее время мы взяли курс на то, чтобы чаще общаться с теми, кто давно живет на наших серверах и готов поделиться с нами своей историей и мыслями.

Один из таких клиентов — Антон Кинстлер, руководитель IT-отдела интернет-магазина мебели «1HMM». И сегодня он расскажет о том, с какими трудностями столкнулась его команда, когда компания решила выйти в онлайн, и какие жизненные уроки из этого вынесла.
1hmm.ru


Предыстория
Наша история началась с маленького магазинчика в городе Верхний Уфалей Челябинской области. В 2011 году был открыт оптовый склад в Челябинске, в 2013-м создали интернет-магазин, а в апреле получили первый заказ через него. Это был многостраничный сайт на 1С-Битрикс: Управление сайтом редакции «Бизнес», и в тот момент на него было заведено около тысячи позиций.

Постепенно интернет-магазин развивался — мы добавляли десятки тысяч новых товаров, оптимизировали сайт, стали использовать такие технологии, как Redis, ElasticSearch, RabbitMQ. Сейчас на сайте свыше 200 тысяч товарных позиций, более тысячи личных кабинетов оптовых покупателей и партнеров, а также десятки миллионов цен.


Сайт интернет-магазина сегодня. Ежедневно его посещают до 50 000 человек
Вообще у нас интересная система. Кроме привычной механики личного кабинета для розничных покупателей и франчайзи, мы реализовали готовый инструмент продаж для наших оптовых покупателей. На базе нашей системы они могут кастомизировать предложенный шаблон, разместить его на своем домене, поставить на товары свои цены, изменить дизайн, добавить свои реквизиты. То есть по факту каждый наш оптовый покупатель получает свой полноценный интернет-магазин, который актуален по ассортименту, остаткам, ценам. И при этом вся работа поддерживается нашими отделами.

Естественно, с ростом проекта требования к серверной инфраструктуре менялись. За семь лет мы успели поработать с разными хостинг-провайдерами, меняли серверы и не раз сталкивались с разными сложностями, которые только добавляли нам опыта. И сегодня я расскажу о трёх уроках, которые кое-чему научили нас за это время.

Урок первый. Как мы просчитались с ресурсами
На старте у нас не было большого трафика на сайт, и мы решили использовать недорогой виртуальный хостинг в Екатеринбурге. Что мы не учли, так это «тяжесть» самого проекта. Дело в том, что помимо большого ассортимента у нас на каждый регион — так исторически сложилось — свой тип цены. Соответственно, у нас десятки миллионов цен (предложений). Поэтому, несмотря на небольшой трафик, мы почти сразу упёрлись в потолок виртуального хостинга. Сайт тормозил, страницы открывались медленно, мы теряли клиентов и деньги. Пришлось срочно «переобуваться» и искать другие варианты.

Мы арендовали выделенный сервер немецкого провайдера с надеждой, что ситуация улучшится. Но и после переезда периодически упирались в ограничения по железу. Часто это было не фатально, но в момент пиковых нагрузок, как правило, заметно снижалась скорость отклика сайта. Как только мы начинали ощущать такие симптомы, то уходили на другие мощности — данные переносили своими силами.

Проект рос быстро, поэтому для нас стал критичным такой параметр, как оперативное и легкое масштабирование. Мы несколько раз меняли провайдеров и порой сталкивались с тем, что у некоторых из них, например, не было возможности добавить аналогичный сервер в том же дата-центре, расширить дисковое пространство или объединить несколько серверов в одну сеть с широкой полосой и низкой задержкой.

Вывод — заранее закладывайте запас по ресурсам
«Переезжать» к новому хостеру каждый раз, когда вы упираетесь в нехватку ресурсов, дело не самое простое – особенно, если у вас большое количество данных. Поэтому теперь мы заранее прикидываем, как будет расти проект и сможет ли провайдер быстро и без проблем добавить нам мощностей при необходимости. Инфраструктура у нас удваивается практически ежегодно, потребности растут — более 50 тысяч посещений ежедневно, а если по хитам смотреть, то по 10 на каждого.

Сейчас у нас нет проблем с масштабированием — просто пишем в поддержку, что нам нужен еще один сервер, и его поднимают.

Урок второй. На хостера надейся, а сам не плошай
Как я уже говорил, какое-то время мы размещали сайт у немецкого хостера, пока он не разочаровал нас. Было несколько остановок, деградировали жесткие диски. На серверах, которые мы арендуем, работает сам интернет-магазин, розничные магазины, франчайзи, партнеры и оптовые покупатели — остановка даже на несколько часов влияет на всех. В сутки мы получаем порядка 1200 заказов. Соответственно, час простоя обходится в потерю примерно ста клиентов. Поэтому для нас так важно, чтобы серверы работали без перебоев.

Столкнувшись с проблемой, мы стали, во-первых, более тщательно оценивать надёжность самого хостера, а во-вторых, уделять внимание резервированию мощностей. Теперь мы стараемся строить структуру так, чтобы при выходе одного сервера из строя, мы могли быстро запуститься на резервном. В некоторых частях системы мы также предусмотрели возможность распределять нагрузку между серверами.

Вывод — обращайте внимание на надёжность хостера и резервируйте мощности
Высокий аптайм означает, что провайдер резервирует мощности и проводит замену оборудования, не приостанавливая работу серверов. При этом ДЦ защищён от пожаров, человеческих ошибок и аварий. Но даже если вы размещаете сайты на серверах самого надежного хостинг-провайдера, не лишним будет подумать о том, как повысить отказоустойчивость своей инфраструктуры.

На данный момент мы добились высокого аптайма всех наших систем. По аренде это возможно дороже, чем содержать собственную систему, но для нас важнее стабильность, поэтому мы выбрали именно такой подход. Сбоев почти не бывает, по мелочи если и были какие-то вещи, то это очень быстро решалось и для пользователей было незаметно.

Урок третий. Сервис с человеческим лицом
Был у нас и такой случай. Довольно долгое время мы хостились у одного из топовых российских провайдеров. Никаких нареканий в техническом плане. И всё шло хорошо, пока мы не столкнулись с проблемой совсем другого характера.

Как-то мы не оплатили вовремя услуги, то ли забыли, то ли платеж по бухгалтерии прошёл поздно — как говорится, с кем не бывает. И нас отключили. Поддержка отвечала очень долго, а позже выяснилось, что в выходные дни она и вовсе не работает — для юридических лиц только в будни. Пока мы разбирались с платежами, серверы были остановлены. И даже после того, как платеж поступил, на включение потребовались сутки. И хотя нас в целом все устраивало, пришлось снова менять хостинг-провайдера.

Вывод — выбирайте круглосуточную техподдержку
Хостинг — это не только серверы, но и люди. Пока сам не столкнёшься с тем, что из-за долгого ответа поддержки можешь потерять клиента, не придаёшь этому особого значения. Сейчас всё гораздо проще. Техподдержка реагирует круглосуточно. Есть услуга обещанного платежа и возможность зачислить деньги при предоставлении платёжного документа. Пока необходимости воспользоваться не было, но это определённо плюс для провайдера.

На старте многие компании не имеют чётко сформулированных требований к хостингу, отсюда форс-мажоры и другие непредвиденные ситуации. Ошибки, на самом деле, — это не страшно, если каждую ты готов анализировать, делать выводы и больше не допускать подобных ситуаций. Зато теперь мы точно знаем, какие критерии при выборе хостинг-провайдера важны для нас, и это помогает нам быстрее решать задачи бизнеса.

https://firstdedic.ru

Каждый кто хоть раз играл в Лего, знает, что даже из малого набора кубиков легко собирается минимум пять вещей. Если приложить усилия, то больше.

Сейчас, когда рынок насыщен техническими и программными решениями, строительство IT-инфраструктуры начинает превращаться в творческий процесс. И только от «строителя», его опыта и знаний зависит, какие «кубики» он предпочтёт использовать, а от каких откажется совсем.

Если раньше компании были более категоричны в выборе — или то, или другое, то сегодня многие склоняются к тому, чтобы объединить преимущества нескольких решений с целью добиться синергетического эффекта. Как это сделали наши клиенты из компании Aristos, которые построили комбинированную инфраструктуру, найдя в ней место и для выделенных серверов, и для облачных технологий.

О подходе к созданию такой IT-платформы, её преимуществах и особенностях рассказывает Андрей Мистулов, технический директор.

Андрей, расскажите, чем занимается компания?

Мы работаем в области ритейла. Предлагаем услуги аутсорсинга электронной коммерции крупным международным брендам. Например, сотрудничаем с Philips, Castrol, Nestle, DeWalt и другими. Создаем и разрабатываем сайты, решаем задачи логистики. Бухгалтерия, закупки, склады — это все завязано на нас.

Наша IT-платформа для интернет-коммерции состоит из множества модулей собственной разработки, приложений и сервисов: CRM, ERP, телефония, логистика, мобильные приложения и так далее. За время работы мы сформировали эксклюзивный набор инструментов и технологий, которые помогают нам непрерывно повышать качество сервиса. Естественно, что такой серьезный инструментарий требует соответствующего фундамента — надёжной и отказоустойчивой архитектуры.

С чего началось строительство IT-платформы?

Первый сервер мы арендовали в 2011 году в Нидерландах — под официальный интернет-магазин Philips. Тогда еще не было 152-ФЗ, который обязывал бы нас хранить персональные данные в России, да и головной офис Philips настаивал, чтобы серверы находились в Европе. На этом сервере хранились и база данных, и веб-сервер, и программный код.

В первые годы работы нам удалось запустить на этой же платформе проекты и для других крупных брендов — Tefal, Olympus, Oursson, Oppo. По мере роста проектов росла и нагрузка. Чтобы её оптимизировать, мы решили перенести базу данных на отдельный сервер.

Так мы работали до 2014 года — в кризис курс доллара резко вырос, а с ним и стоимость серверов в Европе. Арендовать там стало невыгодно, и мы задумались о необходимости переноса инфраструктуры в Россию. Дополнительным аргументом в пользу такого решения стал тот факт, что мы периодически сталкивались с проблемами доступности серверов — для клиентов из России пинг до Европы выше, чем внутри страны. Соответственно, скорость обслуживания медленнее.

Кроме того, нужно было закупать новые серверы. Во-первых, мы расширили команду, специалисты которой нуждались в рабочих инструментах. Во-вторых, под растущие проекты требовалось все больше вычислительных мощностей. Возникла необходимость в сопутствующих серверах и сервисах — препродакшн, тестовые стенды, автоматические тесты и так далее.

К переезду готовились основательно. У нас имелся ряд определенных требований к хостинг-провайдеру, например, собственный дата-центр не ниже уровня Tier II, адекватные тарифы, возможность гибко конфигурировать серверы. Мы несколько недель анализировали рынок хостинговых услуг на соответствие стандартам качества и безопасности, прежде чем выбрали подходящего провайдера.


Мы арендовали три сервера под разные задачи, и на тот момент наша инфраструктура была такой:

• Технический сервер, так называемый dev-сервер, с рядом вспомогательных сервисов (тестовый сервер, git-сервер, мониторинг доступности, сервис управления проектами, телефония и др.).
• Отдельный сервер под базу данных и сервисы, обслуживающие непосредственно интернет-магазины.
• Производительный сервер для обслуживания HTTP-запросов (веб-сервер и обработка запросов со стороны бэкэнд-логики).

С ростом нагрузки возникла необходимость масштабирования вычислительных мощностей. Постепенно мы переработали программную часть инфраструктуры таким образом, что стало возможным запускать ее на неограниченном количестве серверов. Подключили сервис-балансировщик. Его задача — самостоятельно оценивать производительность и нагрузку на каждом из доступных серверов, а затем распределять нагрузку между наименее загруженными серверами.

За счёт этих решений мы смогли реализовать быстрое горизонтальное масштабирование — меньше времени тратить на то, чтобы добавлять новые серверы в общую архитектуру. А кроме того, повысили доступность наших проектов.

Также в первые две недели после переезда мы объединили все серверы в локальную сеть с помощью услуги VLAN. До этого момента серверы общались друг с другом через интернет. И чтобы обратиться к базе данных, требовалось отправить запрос на внешний IP. Такое решение было ненадёжным сразу по двум причинам. Во-первых, сервисы смотрели «наружу», что само по себе не безопасно. А во-вторых, терялась скорость при передаче данных из-за избыточности маршрута. Часть вспомогательных сервисов распределяется между серверами, поэтому нам требовалась оперативная связь между ними. В тот момент этого нам не хватало. Организация локальной сети решила эти проблемы.

Изначально вы строили инфраструктуру только на базе выделенных серверов. По каким причинам решили использовать и облачные технологии?

Дело в том, что спрос на товары брендов, с которыми мы сотрудничаем, неравномерен в течение года. Так высокий сезон у большинства из них начинается в конце года — ближе к праздникам. Кроме того, в течение года бренды запускают акции, рекламные кампании, распродажи, привлекая новых посетителей. В такие моменты нагрузка на серверы возрастает в разы.

Раньше для нас это было серьезной проблемой. Например, традиционно та же «Черная пятница» длилась всего 1-2 дня, а не растягивалась на неделю-другую, как практикуется в последнее время. Чтобы выдержать приток посетителей на клиентские сайты, мы были вынуждены арендовать дополнительные выделенные серверы. И хотя пик посещаемости часто приходился на пару-тройку дней, платили за полный месяц аренды.

Плюс «облаков» в том, что с ними вы получаете почти неиссякаемый резерв вычислительных мощностей. И можете, во-первых, использовать столько ресурсов, сколько нужно, во-вторых, оперативно их подключать, а в-третьих, платить только за те, которые используете.

Поэтому сейчас, когда нагрузка возрастает, справиться с ней нам помогают облачные серверы. Несмотря на то, что облачные решения более дорогие по сравнению с арендой выделенных серверов, такой подход к их использованию позволяет нам экономить.

Вы интегрировали облачные решения в действующую инфраструктуру. Что для этого потребовалось сделать?

Как я уже говорил, сперва мы внедрили ряд решений для быстрого горизонтального масштабирования. Каждый ключевой компонент платформы трансформировался в отдельную операционную единицу с распределенным запуском на разных серверах.

Базы данных (SQL и NoSQL), поисковый сервис, функциональные приложения для работы проекта, API — теперь каждый компонент масштабируется независимо от остальных.

Затем мы подготовили архитектуру платформы для быстрого разворачивания облачных серверов — загрузочные образы включаются в наш стек за считанные минуты. Также автоматически запускается процесс настройки сервера, во время которого активируются сервисы, необходимые для работы.

Облачные серверы связываются с выделенными через IPv6 туннель и WireGuard VPN. А за распределение нагрузки отвечает сервер с системой программной балансировки. Систему разрабатывали самостоятельно, так как хотели иметь полный контроль над поведением балансировщика.

Сейчас это работает так. Система опрашивает серверы, анализирует текущую нагрузку на каждом по нескольким метрикам, исходя из параметров его мощности и количества обрабатываемых задач. В результате анализа присваивает серверу некий «вес» среди всех серверов, обслуживающих конкретный проект. На основе полученного «рейтинга» балансировщик распределяет входящие запросы по наиболее свободным серверам в группе проекта. Так как «опрос» серверов запускается ежеминутно, система реагирует на изменения нагрузки практически в реальном времени.

Вообще мы рассчитываем на то, что этот механизм при необходимости поможет нам в дальнейшем разворачивать дополнительные облачные серверы в автоматическом режиме. Сейчас это делается вручную — пока мы не вводим столько новых серверов, чтобы это стало для нас проблемой.

В результате мы получаем гибкую инфраструктуру, у которой нет ограничений на добавление ресурсов. И при этом все ресурсы используются рационально.

Почему вы не переехали в «облако» полностью?

Облачные серверы стоят дороже. И нет никакого смысла переплачивать за «облако» в спокойный период, когда нагрузка остается в допустимых пределах. В это время мы работаем на мощностях, которые арендуем на постоянной основе. Например, в первой половине года. А облачные ресурсы задействуем на короткие периоды и только тогда, когда это необходимо.

Правда, это не касается облачных дисков. За них мы платим постоянно. Но этот холостой ход не требует больших затрат и позволяет быстро разворачивать данные. Так наша архитектура помогает оптимизировать расходы на серверные мощности.

Расскажите подробнее, какие задачи вам помогает решать комбинированная инфраструктура?

Во-первых, как я уже упоминал, это задача по оптимизации затрат на поддержку и развитие инфраструктуры. Раньше под высокий сезон мы арендовали выделенные серверы стоимостью 15 тысяч рублей в месяц. Теперь на те дни, когда ожидается рост нагрузки, арендуем аналогичные облачные мощности, что обходится нам примерно в 5 тысяч рублей за сервер. В отличие от выделенного сервера «облако», хотя оно и дороже, позволяет не платить за неиспользуемые ресурсы.

А во-вторых, это рост качества наших услуг. Используя гибридное решение, мы повышаем уровень доступности клиентских проектов. К примеру, мы уже знаем, что в зависимости от сезона нагрузка может увеличиваться на 30%, и превентивно в пики посещаемости подключаем дополнительные серверы, чтоб исключить любой риск нехватки ресурсов. При этом в остальное время года используем обычные выделенные серверы — облачные переводятся в режим ожидания, но всегда готовы к моментальному развертыванию.

Такой подход помогает повышать надёжность и при возникновении проблем в работе наших сервисов — в этом случае вышедший из строя сервер немедленно заменяется аналогичным из пула доступных серверов. И процесс не останавливается.

Если нагрузка связана с DDoS-атакой, мы также реагируем на нее введением дополнительных серверов и инструментами фильтрации трафика. К счастью, подобные ситуации возникают редко.

В целом, комбинированная инфраструктура тем и хороша, что учитывает плюсы и недостатки как выделенных серверов, так и облачных. К слову, в выполнении серверных задач отличий нет, потому что принцип один и тот же — использование мощностей. Но нарастить эти мощности проще в «облаке». Чтобы добавить пару ядер, не нужно физически менять процессор.

Подготовка облачного сервера также занимает гораздо меньше времени — за счет готовых образов для развертывания новый сервер вводится в строй в течение 10-15 минут. На подготовку выделенного сервера обычно уходят сутки, так как требуется время на конфигурирование и перенос сервисов. Но при этом стоимость его ниже, а значит в долгосрочной перспективе использовать его выгоднее.

Что необходимо, чтобы поддерживать стабильную работу такой инфраструктуры?

В первую очередь, необходимо, чтобы все элементы инфраструктуры работали согласованно. Поэтому мы в обязательном порядке следим за идентичностью программного окружения, а также проверяем корректность синхронизации локальных файлов.

Но, пожалуй, самое главное — это контролировать работу всех её элементов. В этом нам помогают различные системы мониторинга. Причём, основную работу выполняет Zabbix. Он отслеживает состояние всех серверов по ряду параметров — нагрузка процессора, объём дисков, объём оперативной памяти. А также контролирует работу конкретных сервисов.

Кроме этого, мы используем внешние сервисы мониторинга — для контроля за доступностью сайтов и сервисов. При возникновении проблем, например, если пропал доступ к сервисам, специальные службы на серверах пробуют перезапускать их автоматически. Оповещения о проблемных событиях тут же доставляются в специальный Telegram-канал, где дежурят наши администраторы, готовые оперативно прийти на помощь, если автоматика даст сбой.

При необходимости мы пользуемся услугой платного администрирования нашего хостинг-провайдера. Таким образом, у нас сформирована многоступенчатая защита от сбоев.

Кому бы вы посоветовали использовать комбинированную инфраструктуру?

Думаю, что многие компании так или иначе приходят к подобной схеме работы. Мы рекомендуем использовать аналогичную инфраструктуру любым проектам с периодически меняющейся нагрузкой. Разумеется, сам проект должен быть структурно готов к горизонтальному масштабированию.

В нашем дата-центре появились серверы на базе самых быстрых процессоров AMD Ryzen — топовых 5950X на архитектуре Zen3.

16-ядерный флагман серии Zen3 не только установил рекорд в однопотоке, но также оказался быстрее других AMD Ryzen и Intel Core i9-10900K в рейтинге многопоточной производительности. Посмотреть на результаты тестов можно тут.

Выделенные серверы на базе AMD Ryzen 9 5950X станут универсальным решением для различных задач. Вы уже можете проверить их в действии.

1dedic.ru/amd-ryzen

В линейке выделенных серверов на базе AMD Ryzen пополнение — к заказу стали доступны серверы на новых процессорах Ryzen 9 5900Х.

Технические характеристики процессора:

• 12 ядер;
• 64 Мб кэш-памяти;
• до 4,8 ГГц в турборежиме;
• 3,7 ГГц в базовом режиме.

Ryzen 9 5900X построен на прогрессивной микроархитектуре Zen 3, что обеспечило новому процессору прирост производительности в 19% по сравнению с прошлым поколением. У процессоров поколения Zen 3, в отличии от предыдущих моделей на базе Zen 2, на каждый комплекс CCX приходится вдвое больше кэш-памяти третьего уровня. А максимально близкое расположение элементов на кристалле способствует снижению количества задержек при обмене данными между ядрами и кэш-памятью.

Базовая частота Ryzen 9 5900X достигает 3,7 ГГц, а в турборежиме — 4,8 ГГц. Техпроцесс остался на уровне предыдущих моделей — TSMC 7nm FinFET.

Традиционно перед запуском серверов на базе новых процессоров мы их тестируем. Процессоры AMD Ryzen 9 5900X не исключение, сравнили их с AMD 7 и 9, с другими процессорами 5000 серии, а также с последней моделью Intel Core i9-10900K.

1. Пакет тестов Sysbench используется для оценки производительности процессора в многопоточном режиме. Замеры осуществляются по количеству операций, выполняемых в секунду. Чем выше показатель, тем лучше.

2. Пакет тестов Geekbench показывает индекс производительности для однопоточного и многопоточного режима. Чем выше показатели, тем лучше.

По результатам однопоточных тестов Geekbench, AMD Ryzen 9 5900X значительно обогнал по производительности другие имеющиеся у нас процессоры.

В многопоточном режиме новый процессор AMD тоже показал себя достойно — обошёл почти всех своих предшественников и флагманы от Intel, уступив только Ryzen 9 3950X. Тесты, в которых мы сравнивали AMD на базе Zen 2 с Intel Core i9-9900К, можно посмотреть тут.

https://firstdedic.ru

Чтобы уберечь ваши данные от безвозвратной потери, воспользуйтесь нашей новой услугой «Автоматический бэкап». Вам не придётся тратить время на настройку и мониторинг работы резервного копирования — данные будут регулярно сохраняться в облачном объектном хранилище S3, и вы всегда сможете восстановить информацию из актуальной копии.

Как работает «Автоматический бэкап»

Резервное копирование выполняется автоматически средствами панели ISPmanager или, при её отсутствии, с помощью специального скрипта. Данные сохраняются в фоновом режиме, не мешая работе ваших проектов.

Для хранения используется облачное объектное хранилище Ceph c интерфейсом S3, что гарантирует надёжность ваших данных. При подключении «Автоматического бэкапа» вы получаете возможность хранить до 4 Тб данных. 300 Гб включено в тариф, превышение оплачивается по факту.

«Автоматический бэкап» копирует файлы сайтов, файлы пользователей, настройки сервера. Дифференциальные копии сохраняются каждый день, полные копии — в день подключения, а после раз в неделю по воскресеньям.

Срок хранения копий для серверов с панелью ISPmanager зависит от объёма используемого хранилища, его можно изменить в панели. «Инструменты» — «Резервные копии» — раздел «Ограничения» — «Общий объём» — задайте нужное значение в «гибибайтах» (1 ГиБ = 1.073741824 Гб). Как только хранилище заполнится, новые копии будут записываться на место устаревших.
Срок хранения копий для серверов без панели ISPmanager можно задать в Личном кабинете — «Выделенные серверы» — кнопка «Бэкап» — «Хранить ежедневные бэкапы за … недель». Если объёма хранилища не хватит — вы получите тикет о наличии проблемы.

Создание резервных копий возможно только для активных серверов. При удалении сервера или отключения услуги «Автоматический бэкап» ваши копии также удалятся.

1dedic.ru/content/autobekup

Сегодня на проекте FirstVDS состоялся запуск VDS Storage. Новый тариф для тех, кому важен большой объём дискового пространства. VDS Storage — это до 5000 Гб диска, облачная файловая система на базе Ceph и повышенная отказоустойчивость.

VDS Storage подойдёт для различных задач, например, как площадка для размещения и хранения каталогов интернет-магазинов, баз данных 1С или как сервер для хранения резервных копий. С этим тарифом вы сможете развернуть собственное облачное хранилище, а полный доступ к администрированию VDS позволит настроить и оптимизировать его под свои проекты.

• Быстрый запуск — приступайте к работе уже через 5 минут.
• Бесплатное программное обеспечение NEXTCLOUD.
• Бесплатный перенос ваших проектов от других хостинг-провайдеров.

Заказывая тариф «VDS Storage», вы получаете хранилище объёмом до 5000 Гб с полным функционалом VDS и при этом не платите за избыточные вычислительные мощности.
firstvds.ru/storage-vds

Празднование 18-летия FIrstVDS в самом разгаре.
А вы уже с нами в телеграмме @TakeFirstNews?

Каждый день дарим сертификаты на услуги номиналом 2000 рублей, а 29 декабря в прямом эфире проведём розыгрыш MacBook Air 13 (М1, 2020), iPhone 12 и других классных призов на 300 000 рублей.

Не пропустите всё веселье, присоединяйтесь!
firstvds.ru/happy-birthday-18

Масштабная распродажа готовых выделенных серверов на базе Intel Xeon и Intel Core подходит к концу. Но вы ещё можете успеть заказать сервер со скидкой до 20% — у вас есть 24 часа. Напоминаем, что чем больше срок оплаты при заказе, тем дольше скидка останется с вами.

Готовые серверы — это:

• быстрый запуск — от 15 минут для серверов с ОС Linux,
• бесплатные панели управления ISPmanager 5 Lite, DCImanager,
• большой выбор конфигураций — под любые задачи и требования.

Полный список конфигураций, участвующих в акции, и размер скидок смотрите на странице готовых серверов.
https://1dedic.ru/ready_servers

Поднимаем боевой дух и объявляем старт распродажи — неудержимые скидки

• до 20% на все готовые выделенные серверы на базе Intel Xeon и Intel Core.
• Чем больше срок оплаты при заказе, тем дольше скидка остаётся с вами.

Готовые серверы — это:

• быстрый запуск — от 15 минут для серверов с ОС Linux,
• бесплатные панели управления ISPmanager 5 Lite, DCImanager,
• большой выбор конфигураций — под любые задачи и требования.

Распродажа продлится до конца сентября. Полный список конфигураций, участвующих в акции, и размер скидок смотрите на странице готовых серверов.

Подробные условия акции

• Скидка распространяется на заказ новых серверов в готовых конфигурациях на весь период аренды выделенного сервера при единовременной оплате за указанный период (1, 3, 6 или 12 месяцев).
• Размер скидки — от 14% до 20%, в зависимости от выбранной готовой конфигурации выделенного сервера.
• В течение акции возможен заказ любого количества новых серверов.
• Акция действительна до 30 сентября 2020 года, 23:59 по мск.
• При отказе от сервера по акции скидка на другие услуги не переносится.
• Предложение не действует одновременно с другими скидками и промокодами на выделенные серверы.

https://1dedic.ru/ready_servers