• 15 попугаев: выбираем хостинг-провайдера VPS/VDS-серверов
    0
    Добрый день.
    Есть пара комментариев по вашему обзору.
    «Полоса пропускания 10 Мегабит в секунду. Скорость сети составила 10 мегабит в секунду в обе стороны.» — это гарантированная ширина канала по умолчанию. Пользователь может управлять ей, как на этапе создания, так и в дальнейшем. Канал до 100 Мбит/c можно устанавливать без привлечения поддержки, до 300 — через саппорт. Если арендовать публичную подсеть, то канал можно самостоятельно устанавливать до 1Гбит/c

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

    Спасибо за статью.

  • Ядро Linux 5.1 — что известно об изменениях
    +1
    Посмотрев на комментарие в этой ветке мы решили пересчитать статистику. Приведенное в посте соотношение — это процентовка по всем когда-либо созданным в сервисе виртуальным машинам.

    Если брать активные на текущий момент серверы, то соотношение радикально другое.
    Linux — 44%, Windows — 45%, Другое -11%.
    Пожалуй, эти цифры честнее, т.к. на них меньше сказывается спицфика сервиса на этапах его потсроения, в том числе в маркетинге.
  • Ядро Linux 5.1 — что известно об изменениях
    0
    Вы правы.
    Мы действительно не берем дополнительную плату за лицензию Windows Server. И да, сервис пользуется большим спросом у малого и среднего бизнеса в том числе по этой причине.

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

    Если брать активные на текущий момент серверы, то соотношение радикально другое.
    Linux — 44%, Windows — 45%, Другое -11%.

  • Ядро Linux 5.1 — что известно об изменениях
    0
    Вы заблуждаетесь.
    Мы никакого отношения к 1С не имеем))
    Мы собственно даже лицензии 1Ски не предоставляем.
    Хотя доволно много наших клиентов используют виртуальные серверы именно для хостинга 1С.
  • Почему разработчики дороже денег, как их сохранить и приумножить
    0
    Про то, что за продкутом стоят далеко не только разарботчики — это абсолютная правда.
    Просто в этой статье мы говорили конкретно за разработчиков.

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

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

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

  • Как сделать оплату услуг удобнее: опыт IaaS-провайдера
    0
    В целом клиенты действительно довольны.
    Более того, внедрение автомаплатежа было поднято в приоритетах именно потому, что клиенты его просили. У нас есть целая пачка отзывов, где лиди просят дать такую возмножсть, чтобы не переживать от пропуске оплаты и блокировке сервисов.

    Данные карт у нас не хранятся. В этом суть check-out скрипта.
    Карту привязывает только сам клиент и сумму пополнения определяет тоже он.

    Если же он ошибся с суммой пополнения и хочет вернуть средства, эта всегда можно сделать через обращение в службу поддержки (на те средства, которые еще не были списаны за оказанные услуги).
    Но, в нашей практике подобных проблем с автоплатежом не возникало, по крайней мере пока.
  • Как сделать оплату услуг удобнее: опыт IaaS-провайдера
    0
    Чеки отправляются на финансовый email, если он указан в настройках или на email, указанный при регистрации.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Всегда пожалуйста!
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Таких дисков довольно много
    itprice.com/netapp-price-list/7.6%20tb%20ssd.html
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Преимущества такого расположения наиболее подробно предоставлены в следующих роликах:
    www.youtube.com/watch?v=A_VdNBDKRDg.
    www.youtube.com/watch?v=zElQCERp5vE
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Фейл был знатный, тут даже спорить не станем.
    Тем не менее, ситуацию мы эту отработали, уязвимость закрыли, в процессах учли…
    Человеческий фактор присутсвует везде, к сожалению.
    Но, опять же, учитывая объемы задач связанных с безопасностью и админитсрированием, которые решает iaas-провайдер, накопленный опыт у него, в том числе по отработанным ошибкам, гораздо выше чем у сотрудников обычного ит-отдела.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Рады, что пост понравился. Мы старались.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    image
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    На то он и центр обработки ДАННЫХ.
    Данные сейчас реально становятся чуть ли не главным активом большинства компаний.
    И отношение к ним должно быть соответсвующим.
    По крайней мере мы придерживаемся такой позиции.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Это дейсвительно весомый аргумент.
    Обеспечить схожий уровень безопасности и стабильности, как это делает ЦОД, большинству компаний не под силу, просто из-за масштаба.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Наверное, чтобы освободить место для следующего штурмующего :D
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Да, может.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Пост задумывался именно как фотоэкскурсия.
    + на объекте снимать можно только согласованные места. Там размещено оборудвоание очень многих больших компаний. Не все их них хотят, чтобы их оборудование попало в кадр.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    О каком-либо импортозамещении в рамках серверного оборудования и всего с ним связанного сейчас не может быть и речи.
    Его просто нет по факту. А то что есть — непригодно для коммерческих сервисов.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Это визуальный обман.
    Голова там не пролезет =)
    А даже если форточник с очень маленькой головой протиснится, то что он будет делать дальше?)
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Клиенты очень разные.
    От рядовых пользователей, которым нужно сайт разместить на VDSке, до больших компаний, которые строят на нашей базе распределенную инфраструктруру для своих сервисов, ИТ-отделов и т.д.
    Интеграторы, вебстудии, 1C-франчайзи и вольные админы, фрилансеры всех мастей, маркетологи и т.д.
    Сервис позволяет решать задачи в очень широком диапазоне, потому разных клиенстких кейсов тоже очень много.
  • Большая фотоэкскурсия по московскому облаку 1cloud
    0
    Добрый день.
    Не совсем понятно, с какой проблемой вы столкнулись?
    Напишите, пожалуйста, в личку — разберемся.

  • Критическая уязвимость серверов 1Cloud
    0
    Хорошая идея.
    Посмотрим, что удастся собрать по этой теме.
  • Критическая уязвимость серверов 1Cloud
    0
    Что можно сказать по ситуации описанной в данной статье?…
    Мы облажались. И облажались по-крупному.
    Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
    Естественно, была выплачена компенсация по SLA с округлением в большую сторону.

    Результаты внутреннего расследования инцидента
    В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
    Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
    Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
    Откуда взялся пользователь user?
    При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.

    Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
    Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
    В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.

    Почему последовала неадекватная реакция первого уровня поддержки?
    По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
    1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
    2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
    Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
    Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.

    Что мы сделали, чтобы подобная ситуация не повторилась

    • Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
    • Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
    • Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
    • Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
    • Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.

    Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.

  • Критическая уязвимость серверов 1Cloud
    +2
    Что можно сказать по ситуации описанной в данной статье?…
    Мы облажались. И облажались по-крупному.
    Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
    Естественно, была выплачена компенсация по SLA с округлением в большую сторону.

    Результаты внутреннего расследования инцидента
    В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
    Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
    Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
    Откуда взялся пользователь user?
    При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.

    Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
    Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
    В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.

    Почему последовала неадекватная реакция первого уровня поддержки?
    По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
    1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
    2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
    Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
    Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.

    Что мы сделали, чтобы подобная ситуация не повторилась

    • Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
    • Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
    • Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
    • Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
    • Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.

    Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.

  • Критическая уязвимость серверов 1Cloud
    0
    В процессе установки Debian нельзя пропустить шаг создания непривилегированного пользователя.
    Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
    Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.
  • Критическая уязвимость серверов 1Cloud
    0
    Мы признаем, что уязвимость имела место быть. Клиенту компенсирован простой серверов в соответствии с SLA.
  • Критическая уязвимость серверов 1Cloud
    0
    Windows шаблоны данной уязвимости не подвержены. Но они также будут проверены на предмет других проблем
  • Критическая уязвимость серверов 1Cloud
    +7
    Уязвимость устранена сегодня в 12:08.

    Мы подтверждаем факт обнаружения в одном из наших шаблонов (ОС Debian 8.7) пользовательской учётной записи, с недостаточно крипто защищённым паролем. В следствии чего данный пароль был взломан злоумышленником и в дальнейшем использован при подключении к серверам, созданным из уязвимого шаблона. Эта версия шаблона была опубликована 30.07.2018. Все клиенты, которые использовали указанную версию шаблона, к настоящему времени оповещены о выявленной уязвимости, и приняты меры по её устранению.
    Уязвимости был подвержен 1 из наших 18 шаблонов.
    Количество пострадавших серверов: менее 50 шт.
    Сразу после обнаружения источника проблемы этот шаблон был незамедлительно выведен из эксплуатации. Все остальные публичные шаблоны виртуальных машин проверены на наличие подобной уязвимости.
    Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.
    Предпринятые действия:
    1. Уязвимость устранена в шаблоне Debian 8.7
    2. Проводится дополнительная проверка все остальных шаблонов на предмет других уязвимостей по безопасности
    3. Будет доработана процедура автоматической проверки «золотых» шаблонов на наличие данной ошибки и других уязвимостей по безопасности.
    4. Будет проведены работы с сотрудниками поддержки для недопущения повторения подобных сценариев взаимодействия с Клиентами
    Приносим свои глубочайшие извинения нашим настоящим и будущим клиентам за возникший инцидент. Мы приложим максимум усилий для исключения возможности возникновения подобных ситуаций в дальнейшем.
    Мы планируем предоставить более подробный отчет об устранении данной проблемы и о предпринятых мерах в отдельной статье в нашем блоге.
    Выражаем благодарность пользователю egorbI4 за извещение о серьёзной проблеме, конструктивную критику и взаимодействие!
  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –1
    Да, у нас на каждую ВМ выделено по 10 Мбит\с гарантированной полосы по умолчанию. Оверсейл естественно есть, т.к. весь облачный бизнес на этой концепции и построен. Что это означает: каждый выделенный Мбит\с зарезервирован (минимум по двум независимым каналам связи), при этом если клиент начнет потреблять все выделенные ему Мбит\с то мы гарантируем, что он их получит в 100% объеме в любой момент времени.
    Интернет провайдеры на всех наших площадках не делают разницы между ipv4 и ipv6 с точки зрения тарификации.
    Почему нельзя было сделать dual-stack: такой вариант обсуждался, но от него отказались, т.к. при таком подходе все наши уже выделенные сети пришлось бы заводить в vlan-ы, что потребовало бы значительных трудозатрат и что более важно длительных простоев серверов клиентов. Что конечно же недопустимо для нас.
    На текущий момент vmware vcloud не поддерживает dual-stack. Как только начнет, скорее всего мы модернизируем нашу схему по IPv6.
  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –1
    Ровно тоже самое справедливо и для IPv4 сетей, где блокировка производится в лучшем случае на уровне /24 подсети и в худшем по принадлежности к AS. Именно поэтому все провайдеры (и мы в том числе) так ревностно относятся ко всевозможным рассылкам со своих адресов. И именно поэтому в планах у нас предоставить клиентам возможность заказа выделенной IPv6 /64 подсети. В дальнейшем Клиент сам будет принимать решение, где именно получить адрес:
    1. в shared ipv6 сети
    2. или же заказать выделенную ipv6 /64 подсеть

  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –1
    1. У нас нет «Общего трафика на VM» мы ограничиваем ширину канала связи и не тарифицируем трафик внутри выделенного канала. Т.е. выделяем гарантированную полосу пропускания. Предложенный вами подход подразумевает совершенно другую модель биллинга не за ширину полосы, а за трафик внутри shared полосы.
    2. Насчет того, что канал не будет заметно занят: именно поэтому мы и говорим, что в дальнейшем мы скорее всего отменим данный платеж. Но перед отменой нам необходимо накопить статистику использования. На наш взгляд более честным подходом является: сначала предоставить Клиенту стоимость услуги (если он на нее согласен, то он ее подключит) и в дальнейшем отменить эту абонентскую плату (если данные по использованию позволят), чем поступить наоборот.
    3. «фоне неловкой «популяризации IPv6»»: мы добавили данную опцию для Клиентов, что является позитивным шагом в этом направлении. Мы не навязываем подключение. Предоставили четкий и понятный план постепенного развития данной опции. Не очень понятен негатив с Вашей стороны. Как только мы закончим все три запланированных этапа, Клиенты получат весь комплекс вариантов подключения IPv6 адресов, в том числе и возможность бесплатного подключения IPv6 адреса из shared сети.
    4. Недорогие VPS это не наша целевая аудитория. Мы никогда не пытались и не будем пытаться демпинговать по цене. Наше решение рассчитано на корпоративный сегмент с соответствующими гарантиями по отказоустойчивости архитектуры и SLA
    5. «И, похоже, вам нужно менять провайдера услуг связи, он очень дорого берет за IPv6 трафи» — у нас на каждой площадке минимум по 2 канала связи от различных провайдеров, т.е. каждый выделенный Мбит\с резервируется в 100% объеме. Ни для одного из провайдеров нет абсолютно никакой разницы какой трафик мы пускаете в канал (IPv4 или IPv6). Провайдер тарифицирует выделенную полосу связи и превышение по объему трафика относительно выделенной полосы.
    Надеюсь ответили на все Ваши аргументы.
  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –2
    В Вашем примере у Вас будет два сетевых интерфейса на сервере. Один с IPv4 адресом, другой с IPv6 адресом.
    По умолчанию стоимость канала связи на дефолтный IPv4 адрес включена в стоимость сервера поэтому Вы напрямую ее не оплачиваете.
    IPv6 в данном случае идет как дополнительный интерфейс со своей полосой, которая и оплачивается.
    При подключении дополнительного сетевого интерфейса на сервер в нашей панели управления Вы автоматически получаете не только IP-адрес, но еще и определённую ширину канала связи (по умолчанию 10 Мбит\с) доступную для этого сетевого интерфейса.
    Стоимость 50 рублей в месяц, в случае с IPv6 адресом, обусловлена не самим IPv6-адресом (стоимость которого исчезающе мала), а стоимость выделяемого канала связи на сетевой интерфейс.

  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –3
    Коллеги, в данный момент мы анонсировали только, что у клиентов теперь есть возможность подключить на сервер IPv6 адрес и явно говорим откуда этот адрес будет выделен: из «Общей ipv6 подсети».

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

    Это всего лишь первый шаг в реализации этой функции из трех запланированных:
    1. Подключение IPv6 в общей сети (сделано)
    2. Создание сервера сразу с IPv6 адресом или сразу с обоими.
    На текущий момент столкнулись со сложностями кастомизации IPv6 интерфейса при создании из Windows-шаблонов (решаем)
    3. Заказ /64 выделенной под клиента подсети.
    Сама сеть будет предоставляться бесплатно, а стоимость будет напрямую зависеть от выбранной ширины канала.

  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –1
    Спасибо за обратную связь по сервису, есть что проанализировать. Ниже пояснения по некоторым пунктам Вашего сообщения.

    «Как оказалось, 50₽ нужно платить за каждый IPv6-адрес (/128).» — насчет платы писали в другом комментарии, вероятно в дальнейшем мы отменим данную плату.

    «Поддержка IPv6 есть на всех площадках, кроме Санкт-Петербурга, а я купил именно Санкт-Петербург. Адреса выдаются из одной /64-подсети. Если кто-то будет рассылать спам, почтовый сервер забанит всех клиентов площадки разом.» — В текущий момент поддержки IPv6 нет только на одной из пяти площадок (Санкт-Петербург 1), в СПб-2 опция доступна. Ваши слова насчет рассылки спама, также применимы и к ipv4 адресам. Мы стараемся отслеживать оперативно данные негативные сценарии и заблаговременно блокировать подобный трафик.

    «В любом случае, скорость выполнения действий через панель — какое-то недоразумение. Сервер устанавливался 29 минут, перенастройка сети (отключение и подключение) заняло 30 минут в сумме. Меня не покидает ощущение, что действия по изменению настроек сервера выполняются людьми, а панель только создает тикеты.» — Это не так, все действия автоматизированы. Мы посмотрели нашу аналитику, Ваш тест совпал с регламентными работами по добавлению новых хостов в кластер, в подобные моменты в кластере наблюдаются задержки с выполнением менеджмент операций, при этом никак не сказывается на работе виртуальных машин. Предлагаем Вам повторить тест по созданию сервера и по работе с сетевыми параметрами. Средства на проведение тестирования готовы предоставить дополнительно.

    «I/O на сервере низкий — первое подключение по ssh заняло 15 секунд(!), man man выполнялся 4 секунды (но я взял сервер со «средней» производительностью, а первоначально предлагали с «высокой», сам виноват).» — Предполагаем, что со вторым подключением к серверу проблема не повторится, просьба написать, если это не так.

    «После удаления «публичной сети» (и IPv4-адреса), заново получить IPv4-адрес нельзя, предлагают заплатить 100₽.» — да, это сделано намеренно, т.к. с точки зрения системы Вы выполнили действия, напоминающие перебор IP адресов. Это правило предусмотрено в целях защиты зловредной активности.
  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    0
    Да, ошибка закралась на этапе верстки статьи. Спасибо, что обратили внимание.
  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –4
    По умолчанию сервер создается с IPv4. После этого в панели управления в разделе сервера -> Настройки -> Сети можно включить IPv6.
  • Как дела с IPv6, или что тормозит переход на новую версию протокола — обсуждаем ситуацию
    –3
    Переход на IPv6 в любом случае предполагает определенные расходы для компаний (особенно, если в компании хотят произвести его своими силами). В данном же случае провайдер позволяет как раз с очень небольшими затратами поэкспериментировать с использованием протокола. Поэтому тут имеет смысл сравнивать не столько стоимость IPv4 и IPv6, сколько выгоды от внедрения протокола IPv6 лично для вас.
  • Немного статистики — разработчики Ubuntu впервые опубликовали десктопную телеметрию
    0
    Если говорить про нашу статистику установки на VPS.
    Поскольку мы не малый хостер, и у нас представлены все основные дистрибутивы Linux, то статистика получается довольно честной.
    Можно оспаривать как раз перекос в сторону Windows Server, упирая на особенности целевой аудитории сервиса. Но, в разрезе полпулярности Linux дистрибутивов данные вполне можно считать репрезентативными.
    А чтобы использовать друой дистрибутив (не представленный в шаблонах для создания), можно просто взять свой ISO и передать поддержке. Они примонтирую его к пустой виртуалке… расскатываете, пользуетесь. Можно в догодку на базе этой виртуальной машины сделать свой пользовательский шаблон и дальше разворачивать из него машинки со столь милым сердцу дистрибутивом.
    Чтобы быть совсем честным, нам конечно стоило добавить Иное. Но, по нашим цифрам эта категория попадает в пределы статпогрешности.
  • Регулирование: В США обяжут компании уведомлять об утечке ПД в рамках 30 дней
    0
    Не все сервисы при регистрации пользователей запрашивают почтовый адрес или телефон для связи. В таком случае остается email (но есть исключения, о которых выше рассказали).