Здравствуйте, уважаемые клиенты!

Сегодня была добавлена тарифная линейка виртуальных серверов «FR-GAME».

Основная информация о линейке:

• Локация: Франция/Страсбург
• Датацентр: OVH
• Виртуализация: KVM
• Канал: 100 MBPS/unlim

• FR-GAME-1
• CPU: 1 X 4.0 GHz
• RAM: 1 GB DDR4
• HDD: 20 GB SSD
• Стоимость: 399 ₽
• Заказать

Вы можете ознакомиться с тарифами линейки или перейти в панель управления для заказа виртуальных серверов.

Кейп-Норт, для остальной части нашего тура! Мы продолжаем обзор наших инфраструктур с шагом в центре обработки данных Gravelines (GRA). Всего в 60 километрах от штаб-квартиры, это одна из крупнейших команд в отраслевом бизнес-подразделении с 60 сотрудниками на площадке, разделенная на несколько технических команд, обеспечивающих присутствие на месте 24/24, 365 дней в году.


В настоящее время два центра обработки данных Gravelin GRA 1 и GRA 2 могут вмещать более 85 000 серверов.

Площадь общей площади более 9 гектаров, включая 20 000 м 2 зданий, расширилась. Чтобы реагировать на рост и безопасность, на этом участке в этом году есть дополнительная линия высокого напряжения. Электрическая мощность составляет 40 МВт


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

Чтобы обеспечить высокую доступность всего сайта, каждый источник питания, помимо избыточности, сбрасывается инверторами. Установка генератора систематически устанавливается параллельно, как показано ниже.


Команды R&D OVH также продолжают внедрять инновации, в частности, для повышения энергоэффективности центров обработки данных. В этом контексте Gravelines скоро получит новые технологические достижения, к которым мы вернемся.

careers.ovh.com/fr/offres/site-reliability-engineer-containers-hf

Если мы немного разъясним, вот связанные миссии:

• Сократите наши эксплуатационные расходы и автоматизируйте лучшие решения по всем возникающим трудностям и проблемам
• Оцените важность сообщений о проблемах с инфраструктурой OVH
• Предложите и помогите внедрить передовую практику и меры, чтобы инциденты случались только один раз и никогда больше .
• Обеспечение непрерывности обслуживания с обязанностями по вызову (24/7 производственная среда)
• Работа с командами для выявления, устранения узких мест для повышения производительности и сокращения затрат.
• Предоставлять поддержку владельцам приложения, позволяя им защищать свои платформы
• Короче говоря, вы работаете с современными инструментами с открытым исходным кодом, одновременно поддерживая критически важные системы, предлагающие широкий спектр приложений. Мы рассчитываем на то, что вы бросите вызов дизайну, архитектуре и масштабируемости инфраструктуры и сыграете жизненно важную роль в улучшении стабильности наших продуктов и инфраструктуры.

Хорошие новости для всех тех, кто интенсивно использует хранилище в Public Cloud: мы приступили к развертыванию как аппаратных, так и программных оптимизаций, которые позволяют нам в долгосрочной перспективе демонстрировать повышенную производительность на всех экземплярах и регионы. Прирост не является анекдотическим: на примере типа B2-7 мы, например, находимся от 2000 IOPS до 20 000 IOPS, что составляет 10!

Прежде чем вдаваться в подробности этих оптимизаций, немного истории. В самом начале виртуальные машины, размещенные в Public Cloud, были связаны с удаленным хранилищем: это было логическое решение с точки зрения объединения, но латентность сети ограничивала производительность в больших масштабах. Поэтому мы быстро решили переключиться на локальное хранилище, а затем настроили избыточность. С этим локальным SSD RAID мы думали, что достигли очень хорошего уровня производительности.

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

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

Параллельно речь шла о файловой системе .LVM дал отличные результаты в синтетических тестах, но производительность оказалась менее привлекательной с применением тестов, соответствующих реальности поля: на практике наши клиенты, которые интенсивно используют Redis, MongoDB или Hadoop, не ограничены для выравнивания блоков 4K. Новый эталонный этап был необходим с более представительными инструментами.


Сравнение различных форматов хранения, сравниваемых командой OVH Metrics. В красном: характеристики PCI Raw с io = native на NVME. В оранжевом цвете, полученные с LVM, и в желтом цвете, сделанные с виртуальными машинами перед оптимизацией. Наконец, зелёным, производительность выделенных серверов, которая является стандартной мерой, которую мы пытаемся подойти, «Нижняя лучше».
Как показано в вышеприведенном тесте, результаты, полученные с помощью RAW, оказались очень близкими к результатам выделенных серверов.

В конце этого процесса мы предложили некоторым клиентам проверить правильную комбинацию, а именно переход из Qcow в RAW и файловую систему на основе оптимизированной версии Ext4. Хорошая новость, она единогласна среди первых клиентов-тестировщиков: они измеряют производительность в IOPS до десяти раз выше, как показано на скамьях ниже.



Миграция
Теперь идет вторая фаза: развертывание в больших масштабах, чтобы сделать эти улучшения доступными как можно большему количеству людей. Сайт займет немного времени: требуемое оборудование и его конфигурация требуют действительно последней версии OpenStack, Newton, по которой все наши инфраструктуры постепенно мигрируют. Хорошей новостью является то, что эти оптимизации не влияют на цену или номенклатуру наших экземпляров Public Cloud: они просто интегрированы в существующее предложение. На самом деле, вы даже можете наслаждаться этим!

Если IOPS является критерием выбора для ваших действий в облаке, мы предлагаем вам получить конкретное представление о производительности, предлагаемой несколькими щелчками мыши: вам просто нужно запустить VM B2 (General Purpose), размещенный в регионе GRA5.

А после?
Мы считаем, что интенсивное использование ввода-вывода имеет место в нашем общедоступном облаке. Параллельно с текущей миграцией мы готовим следующий шаг, который еще больше повысит уровень производительности на 10. Не заходя слишком далеко в детали предложения, все еще находящегося на стадии «незавершенного производства», просто представьте, что ваша виртуальная машина когда-нибудь сможет получить доступ в переходе PCI к кластеру SSD NVMe, установленному в соответствии с выбранным вами RAID и выделенным к вашим потребностям…

• LSCache теперь доступен всем клиентам виртуального хостинга. Подробнее о lscache
• У бэкапов убраны жёсткие квоты, вместо этого теперь мы предлагаем оплатить за превышение. Лимит места был увеличен для того, чтобы можно было делать новый бэкап, не удаляя старый.
• В личном кабинете для бухгалтерии теперь можно создавать запросы и вести переписку с нашей бухгалтерией.
• На сайте появился калькулятор тарифов, чтобы легче было подбирать наиболее выгодный тариф.

• Файловый менеджер теперь доступен на хостингах с панелями cPanel и ISPmanager, а также для заказов места под резервные копии.

www.ihc.ru

Использование watchdog I6300ESB в виртуальных машинах в Cloud2
Сегодня мы расскажем о полезной возможности Cloud2, которая позволяет повысить доступность виртуальных машин за счет использования виртуального устройства watchdog, которое доступно внутри VPS.

Сначала несколько слов о том, что такое watchdog. В апаратных серверах промышленного класса всегда есть специальная микросхема, которая работает автономно от всего и представляет собой обычный таймер с действием при достижении нуля. По умолчанию, таймер отключен и действие не установлено, но с помощью специального программного обеспечения, например, ipmitool, можно это изменить и задать определенное поведение — например, перезапуск сервера через reset при достижении нулевого значения, а начальное значение, например, установить в 360 секунд. Далее, в системе запускается специальная программа, которая просто обновляет таймер, не давая ему достигнуть нулевой отметки. Таким образом, пока система работает и процессы выполняются, таймер обновляется и watchdog не срабатывает, однако, как только операционная система зависла, программа, обновляющая таймер перестает работать тоже. В течение максимум 360 секунд счетчик достигнет нулевой отметки, и система перезагрузится с помощью виртуального нажатия на кнопку «reset». Механизм абсолютно надежный, поскольку работает на уровне аппаратного обеспечения, позволяя администраторам в большинстве случаев значительно уменьшить время недоступности систем при возникновении ошибочных ситуаций.

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

Реализация в Cloud2. В Cloud2 используется гипервизор KVM, который поддерживает watchdog на базе микросхемы Intel i6300esb, эмуляция которой и осуществляется гипервизором. Мы задали действие для watchdog как reset, таким образом при зависании машина будет перезапускаться.

Использование watchdog в Cloud2. Использование i6300ESB в ОС Linux не представляет труда. Для начала использования необходимо выполнить следующие действия (Ubuntu Linux 16.04):

Установить ПО watchdog:

# apt-get update && apt install watchdog

Узнать как собрана поддержка устройства I6300ESB для вашей ОС:

# grep I6300ESB /boot/config-$(uname -r)
CONFIG_I6300ESB_WDT=m

Если «m», значит, модуль необходимо загрузить. Если «y», значит, что поддержка встроена в ядро, если «n», требуется пересборка ядра. Скорее всего, у вас будет «m», если это так, необходимо установить дополнительные компоненты ядра:

# apt install linux-image-extra-$(uname -r)

Теперь можно загрузить модуль:

# modprobe i6300esb
# lsmod | grep i6300esb
i6300esb 16384 1

Видим, что все отлично — модуль загружен. Теперь необходимо добавить его для автоматической загрузки. Пакет watchdog в Ubuntu позволяет сделать это через добавление параметра в настройки запуска сервиса watchdog:

# cat /etc/default/watchdog 
run_watchdog=1
run_wd_keepalive=1
watchdog_module="i6300esb"

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

watchdog-device = /dev/watchdog

в файле /etc/watchdog.conf.

Выполним запуск сервиса watchdog:

# service watchdog start

Если запуск прошел успешно, то в журнале /var/log/syslog, Вы увидите следующие записи:

Oct 2 03:55:08 sop watchdog[22526]: test=none(0) repair=none(0) alive=/dev/watchdog heartbeat=none to=root no_act=no force=no
Oct 2 03:55:08 sop watchdog[22526]: watchdog now set to 60 seconds
Oct 2 03:55:08 sop watchdog[22526]: hardware watchdog identity: i6300ESB timer

Если система зависнет, то в течение 60 секунд для нее будет выполнено действие «reset». Убедитесь, что сервис watchdog корректно стартует после перезапуска системы.

Проверить работоспособность можно посредством генерации состояния Kernel Panic:

echo c > /proc/sysrq-trigger

Не более чем через 60 секунд система должна перезагрузиться.

В статье приведена настройка только для Ubuntu Linux. Для Debian, CentOS и других ОС семейства Linux настройка будет похожа. Настройка для других операционных систем (MS Windows, *BSD и других) осуществляется посредством интерфейсов и приложений, которые в них предоставляются для взаимодействия с таймером i6300esb и в этой статье не рассматриваются.

В RU-CENTER стартовал прием предзаказов на доменные имена в новой универсальной зоне .page.

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

В целях развития безопасного интернета правилами доменной зоны .page предусмотрена возможность использования имен только для сайтов, доступных по протоколу https. Для его настройки владельцам доменов потребуется валидный SSL-сертификат — для клиентов RU-CENTER на первый год он выпускается бесплатно.

RU-CENTER принимает заявки на премиальную и открытую регистрацию доменных имен .page. Стоимость доменов — от 1 290 рублей.
www.nic.ru/catalog/domains/page/

Уважаемый Абонент,
с 01 октября 2018 года ООО «ТК МАРОСНЕТ» применяет общую систему налогообложения в соответствии с пунктом 4 статьи 346.13 НК.
Цены не изменились и включают НДС.
www.ihor.ru/documents/2018/vat-letter.pdf


Читать дальше →

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

Почему нам нужно использовать суррогатные ключи? Совершенно просто: вопреки естественным ключам они сохраняются с течением времени (т. Е. Они не привязаны ни к каким бизнес-значениям), и они допускают неограниченные значения. Подумайте о таблице, которая собирает данные IoT с нескольких устройств в разных регионах: поскольку вы хотите хранить неограниченные данные, и у вас могут быть возможные совпадения с идентификаторами устройств, суррогатные ключи помогут многозначительно идентифицировать запись. Другим вариантом использования может быть таблица «items», в которой вы хотите хранить информацию, связанную не только со статьями, но и с историей изменений, сделанных на данных: даже в этом случае суррогатные ключи могут быть изящным решением, позволяющим легко присваивать уникальные идентификаторы всем записям



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

ROW_NUMBER() OVER({window_name | (window_specification)})

SELECT 
	ROW_NUMBER() OVER() AS SurrogateKey,
	*
FROM `bigquery-samples.wikipedia_benchmark.Wiki1M`

К сожалению, этот подход ограничен. Для реализации ROW_NUMBER () BigQuery необходимо сортировать значения в корневом узле дерева выполнения, который ограничен объемом памяти в одном узле выполнения.

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


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

Возможны два возможных подхода:

INSERT INTO, когда новые записи должны быть вставлены в таблицу (воспроизведение с внутренним запросом для выбора целевых данных, которые необходимо вставить в таблицу целей)

INSERT INTO `MyPrj.MyDataset.Wiki100B_With_SK`
(SurrogateKey,year,month,day,wikimedia_project,language,title,views)
SELECT (SHA256(title)) AS SurrogateKey,*
FROM `bigquery-samples.wikipedia_benchmark.Wiki100B`

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

UPDATE `MyPrj.MyDataset.Wiki100B_With_SK`
SET SurrogateKey = (SHA256(title))
WHERE year = 2010

Когда вы планируете свои действия, обратите внимание, что вы ограничены 1000 операций INSERT на таблицу в день и 200 операций UPDATE на таблицу в день.

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



Другим способом достижения такого же результата является использование новой функции GENERATE_UUID (), которая генерирует уникальный идентификатор для каждой строки результата запроса во время выполнения. Сгенерированный ключ будет строчной строкой, состоящей из 32 шестнадцатеричных цифр в пяти группах, разделенных дефисом в форме 8-4-4-4-12.

SELECT 
GENERATE_UUID() AS SurrogateKey,
*
 FROM `bigquery-samples.wikipedia_benchmark.Wiki100B`

Вывод
Суррогатные ключи распространены в средах хранилища данных, поскольку они:

• Контекстно-независимый
• Больше совместимости с будущим
• Потенциально бесконечно масштабируемый

BigQuery предоставляет конечным пользователям возможность легко справляться с суррогатными ключами, позволяя их генерировать и обновлять по шкале.
cloud.google.com/blog/products/data-analytics/bigquery-and-surrogate-keys-practical-approach

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

С хорошо разработанным планом DR, вы можете убедиться, что если катастрофа ударит, влияние на нижнюю строку вашего бизнеса будет минимальным. Независимо от того, как выглядят ваши требования к DR и независимо от того, где ваша производственная среда (на месте, в облачной платформе Google (GCP) или другом облаке), GCP имеет гибкий и экономичный выбор продуктов и функций, которые вы можете использовать для создания или расширения решения DR, которое подходит именно вам.

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

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

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

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

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

Если вы предпочитаете смотреть видеоролики, мы вас охватили. Этот сеанс из Next '18 дает обзор проектирования и внедрения DR-систем в GCP. Вы также можете ознакомиться с некоторыми нашими партнерскими решениями, предназначенными для планирования DR.