FirstDedic Хостинг

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

Один из таких клиентов — Антон Кинстлер, руководитель 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

С днём рождения, Linux!
25 августа 1991 года финский студент Линус Торвальдс в почтовой конференции Minix объявил, что закончил работу над первой версией ядра Linux. Тогда оно выглядело как некоторое подобие операционной системы и нуждалось в существенных доработках — но начало было положено.

В честь такой даты предлагаем вспомнить интересные факты о Linux.

• Линусу Торвальдсу на момент написания первой версии ядра был всего 21 год.
• Сначала ОС планировалось назвать Freax, однако Ари Лемке, преподаватель Торвальдса, который разместил ядро на файловом сервере института, назвал каталог Linux в честь его создателя.
• Известный маскот в виде пингвина по имени Tux (Torvalds UniX) был предложен самим Торвальдсом и выбран в ходе голосования логотипов в 1996 году (хотя по количеству голосов проиграл графическому изображению названия Linux).
• 17 сентября 1991 года в свет вышла первая публичная версия Linux. С тех пор ОС значительно выросла и получила мировую популярность.
• Изначально ядро имело в себе 10 239 строк исходного кода, текущая же версия Linux 5 насчитывает в себе более 26 миллионов строк.

Поздравляем Linux и всех причастных! Но это не единственная хорошая новость на сегодня: мы снизили стоимость превышения трафика на гигабитном канале более чем в 2 раза! Теперь цена за каждый ТБ сверх пакета составит 230 рублей вместо 512 — ещё выгоднее, чем раньше.
1dedic.ru/additional/gbit_kanal