У нас стала доступна для заказа услуга VPN. Сейчас она предсставлена двумя тарифами:

• CUSTOM-VPN
• настройка VPN на ранее заказанном сервере
• 199 ₽ за установку
• Заказать

• COMPLEX-VPN
• Заказ VPS с предустановленным VPN
• 199 ₽ за установку и 99 ₽ ежемесячно
• Заказать

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

Global Colocation Brand Datacenter.com обеспечивает соответствие стандартам PCI DSS (безопасность) и ISAE (аутсорсинг услуг)

Амстердам, Нидерланды, 25 июня 2018 г. — Datacenter.com, глобальный поставщик услуг колокейшн по требованию, который заплатил более 500 000 долларов США за свое доменное имя, с его первым крупномасштабным центром данных Colocation AMS1, расположенным в Амстердаме, Нидерланды, достигнута сторонняя сторона подтвердила соответствие стандартам PCI DSS 3.2 и ISAE3402. Сертификаты гарантируют, что Datacenter.com имеет средства контроля корпоративного уровня для защиты данных платежей, одновременно защищая эффективность своей системы внутреннего контроля (ICS) как сервисной организации и глобального поставщика профессиональных решений по аутсорсингу ИКТ.

Сертификация PCI DSS (стандартная система безопасности данных платежных карт) была бы важной аккредитацией для финансовых компаний и торговцев электронной коммерцией, размещенных в помещениях Амстердама Datacenter.com. Стандарт PCI DSS 3.2 предоставляет набор политик и процедур, предназначенных для обеспечения клиентам Datacenter.com, что их карточные данные и финансовые транзакции в этой среде центров обработки данных Colocation в Амстердаме всегда защищаются в любое время.

ISAE3402 — международный признанный стандарт аутсорсинга для сервисных организаций. Он предоставляет клиентам Datacenter.com уверенность в том, что их (конфиденциальные) данные защищены должным образом и придерживаются строгих правил конфиденциальности. В нем также рассматриваются возможности управления рисками, а также меры по борьбе с мошенничеством с учетом выявленных рисков.

Утверждение стороннего соответствия Datacenter.com для этих сертификатов PCI DSS и ISAE3402 не требовало каких-либо дополнительных корректировок при завершении работы, сказал Jouke Albeda — менеджер по безопасности и соответствию на Datacenter.com, в основном из-за его предыдущего опыта работы в качестве ИТ-аудитора для EY и БДО. «Являясь ИТ-аудитором для нескольких консалтинговых фирм, я провел много ИТ-аудитов, включая соблюдение ISAE для компаний в индустрии центров обработки данных», — сказал Жук Альбеда. «Теперь, когда я работаю на стороне клиента, мой обширный опыт в области ИТ-аудита очень полезен, и мы не прилагаем столько усилий, чтобы помочь нашему AMS1-объекту в Амстердаме успешно подготовиться к этим аудитам соответствия».

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

«Благодаря моему обширному опыту в области ИТ-аудита мы можем получить дополнительную милю для наших клиентов, когда речь идет о требованиях к их соблюдению», — добавил г-н Альбеда. «Что касается PCI DSS, например, вы должны сначала определить область, к которой могут применяться элементы управления PCI DSS. После определения вашей области действия вы должны применить все элементы управления безопасности в стандарте к содержащейся среде, которую вы определили. Излишне говорить, что обширная область PCI DSS, как правило, приводит к более сложной траектории соответствия, которую сложнее достичь. Не в нашем случае. Мы решили даже включить управление жизненным циклом данных клиентов в нашу компетенцию PCI DSS ».

Таким образом, для Datacenter.com достижение сертификации соответствия PCI DSS означает, что компания теперь даже имеет стороннюю аккредитацию для безопасной обработки клиентских носителей данных. «Являясь поставщиком чистых игр, мы ориентируемся исключительно на предоставление услуг центров обработки данных Colocation, например, мы не используем облако», — сказал Йохем Штеман, генеральный директор Datacenter.com. «Мы внимательно следим за потребностями наших клиентов, включая CSP, предприятия, вещательные компании и онлайн-провайдеры. Предоставление наших колокейшн-услуг по требованию с ежемесячными контрактами является важным активом в нашем портфеле продуктов. Он удовлетворяет потребности облачных провайдеров и предприятий. Мы также ожидаем, что управление жизненным циклом данных станет довольно интересным сервисом, так как это освободит наших клиентов-колокейсов, помогая им защищать свои данные от конца до конца ».

PCI DSS включает набор стандартов безопасности, созданных в 2004 году Visa, MasterCard, Discover и American Express. ISAE3402 был разработан IAASB (международным советом по стандартам аудита и сертификации), предписывая отчеты по управлению организацией (SOC), сначала публикуемые в 2011 году. В качестве менеджера по безопасности и соответствию Datacenter.com г-н Альбеда не только сосредоточен на соблюдении этих требований аккредитаций. Другие сертификаты, уже достигнутые или планируемые для получения, включают ISO27001, ISO14001 и ISO9001.

Закажите сервер на 3 месяца и получите 4-ый месяц в подарок — предложение действует до 30 июня. Так вы с толком используете “сгорающий” бюджет и не будете переживать, что сервер простаивает (потому что летом все в отпусках и заниматься новыми проектами некому).

Акция действительна для готовых выделенных серверов. Закажите такой на период от 3 месяцев с промокодом SUMMERBUY. После активации сервера срок действия продлится на месяц.
1dedic.ru

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

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

1. автоматически отслеживать изменения и сохранять их для будущего анализа;
2. отслеживать историю изменений каждого файла с возможностью доступа к историческим состояниям и сравнения текущего состояния с историческим;
3. безопасность хранения изменений и самих конфигурационных файлов;
4. отслеживание изменений конфигураций нескольких серверов.

Хочется, отметить, что, при применении средств непрерывной автоматизации конфигураций (continuous configuration automation), подход, который мы обсуждаем здесь не будет иметь большой пользы, но, как правило, такие инструменты как Ansible, Chef, Puppet применяются только при управлении большими парками серверов. Применяющие же данные инструменты люди вполне осознают как добиться эффективного отслеживания изменений.

Итак, для начала работы необходимо определиться с провайдером Git. Вы можете самостоятельно установить и настроить Git, но для использования Git с удобным интерфейсом, позволяющим делать анализ изменений online, я рекомендую воспользоваться Gitlab. Образ для Docker можно взять здесь, а его настройка описана в официальной документации. Однако, некоторым администраторам будет проще купить платный аккаунт на GitHub за 7 долларов, в котором можно организовать неограниченное количество приватных репозиториев как для целей задачи управления конфигурациями, так и для иных скриптов. Далее, в данной статье будем считать, что используется GitHub. Мы будем использовать публичный репозиторий и давать ссылки на него.

Для решения задачи нам понадобится репозиторий Git, будем считать, что в каждом репозитории будет каталог с именем сервера, в котором будут отслеживаться конфигурационные файлы для этого сервера, например, для файла /etc/passwd с сервера jupiter:

configurations/jupiter/etc/passwd

Возможно организовать работу таким образом, чтобы все изменения конфигурационных файлов переносились в Git. Для этого можно воспользоваться инструментарием Inotify, например, inotifywait, однако, это кажется избыточным в общем случае. В рамках данной инструкции будем считать, что синхронизации 1 раз в час достаточно для нормального отслеживания изменений.

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

Итак, для выполнения нашей цели определим пути файлов конфигураций, которые будем отслеживать. Обычно, /etc, /usr/local/etc, но у Вас могут быть и другие. Будем считать, что в рамках задачи мы отслеживаем пути:

/etc
/usr/local/etc

Рассмотрим, как будет выглядеть общая схема работы нашей системы по шагам:

1. периодически будем переносить изменения из отслеживаемых каталогов в репозиторий с помощью rsync;
2. каждый день в репозитории создается отдельная ветка для состояния предыдущего дня, в которую помещаются изменения на этот день;
3. в ветке master всегда будет находиться текущая конфигурация.

Особого внимания заслуживает пункт «2». Часто администратору требуется восстановить конфигурацию на какой-то конкретный день. Создание ветки для каждого дня позволит решить эту задачу.

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

Создание репозитория
Итак, для начала необходимо создать репозиторий Git, в котором мы планируем хранить конфигурации. В случае GitHub, данная задача решается следующим образом (у нашей компании на GitHub имя пользователя netpoint-dc:

echo "# configurations" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:netpoint-dc/configurations.git
git push -u origin master

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

Установка клиента Git на сервер
Для Debian, Ubuntu

apt-get update && apt-get install git

Для CentOS

yum install git

Генерация файла ключей SSH для доступа к Git
Доступ к Git возможно осуществлять по протоколу SSH, для этого необходимо положить публичную часть ключа на сервер Git. В GitHub это делается по данному адресу. Сам же ключ необходимо сгенерировать командой:

ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:wBHTpwEdejAhByHJ9R/pajk3WNfofpJWEE+2I46dgoM root@git-config-article
The key's randomart image is:
+---[RSA 2048]----+
| ..o=oX*..       |
| o. = *+.o o     |
| = ++ = .        |
| =..oo+          |
| . .S+o+..       |
| E o=oo+ .       |
| *.o..o          |
| . o o+ .        |
| ..o             |
+----[SHA256]-----+
root@git-config-article:~#

Публичную часть ключа необходимо добавить на Ваш сервер Git (для GitHub адрес):

cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFrbYQFrRHTFrcvy4N3n/rKj9qWJfpjrka7MnzpH0lvU1TllOgKD4XqP4a3CIr7lMgnkBtoXQcKHgYtX9aeMVUSLKCkNj0yxbIzcGaQi/fe5YBpAk7sKhpVwHXYqnrL9WVf9ZQ/D3uI/M9lxUZwj6TuBXYIsBx/+oe5kKhS01GhXYsFyWKLMUHS/NLaozPH9lFoa4fiQqi4Z9oK2pPzpz+AyiGV+yOxry/RlXtkq2KnB4qRkdf907zC94zIVRxPjZbvlvNlRCf2PLSAMnGkNorVdIjEP+b0tY+H8STeoo9PT6Pyt7IusMEqy4l8ppLqzbDpfPId5/6YbOk4CnaEVOJ root@git-config-article

Инициализация репозитория Git

Обратите внимание, мы используем для доступа к Git протокол git://. Если Вы планируете использовать протокол HTTPS, то Вы будете использовать аутентификацию по паре login/password, что не очень удобно.

mkdir configurations
cd configurations
echo "# configurations" >> README.md 
git init 
git add README.md 
git commit -m "first commit" 
git remote add origin git@github.com:netpoint-dc/configurations.git
git push -u origin master

Если все прошло успешно, то Вы должны получить сообщение, похожее на следующее:

root@git-config-article:~/configurations# git push -u origin master
The authenticity of host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts.
Counting objects: 3, done.
Writing objects: 100% (3/3), 241 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:netpoint-dc/configurations.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.

А в репозитории Git — репозиторий с таким содержимым.

Наполнение репозитория файлами
Для решения данной задачи воспользуемся командой rsync:

mkdir -p /root/configurations/$(hostname)
rsync -av /etc /usr/local/etc /root/configurations/$(hostname)/

Если Вы отслеживаете большее количество каталогов, то их просто необходимо добавить в перечень отслеживаемых. После переноса файлов необходимо их добавить новые в Git:

find /root/configurations/* -exec git add {} \;
git commit -a -m «Configuration updated at $(date) from $(hostname)»

Загрузим файлы в удаленный репозиторий:

git push

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

Создание ветки конфигурации на дату
Создадим ветку с состоянием текущей конфигурации на данный день и загрузим его в репозиторий Git.

git checkout -b $(date +"%Y-%m-%d")
git push origin $(date +"%Y-%m-%d")

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

#!/bin/bash

if [ "$#" -lt 2 ]
then
  echo "At least 2 or more parameters should be passed"
  echo "Usage: syncer.sh /path/to/repo /path/to/configs [/path/to/other/configs ...]"
  echo "--"
  echo "Avoid final slashes when specifying config directories if the intention is to"
  echo "have dir rather than dir contents"
  exit
fi

REPO_DIR=$1 # где хранится репозиторий
shift
DIRS=$@ # какие каталоги синхронизуем

echo "Repository is located at "$REPO_DIR
echo "Configuration dirs are located at "$DIRS

HOSTNAME=$(hostname)
TODAY=$(date +"%Y-%m-%d")
HOUR=$(date +"%H")

echo "Hostname is "$HOSTNAME
echo "Today is "$TODAY

cd $REPO_DIR

# выкачаем обновления с сервера
git pull
# переключимся на master ветку, куда добавляем изменения
git checkout master

mkdir -p $REPO_DIR/$HOSTNAME

# добавим новые файлы в репозиторий
rsync -av $DIRS $REPO_DIR/$HOSTNAME/
find $REPO_DIR/* -exec git add {} \;

# сохраним изменения
git commit -a -m "Configuration updated at $(date)"

# отправим изменения на сервер
git push

# если последняя синхронизация в сутках, создадим ветку для сегодняшнего дня
if [ $HOUR = "23" ];
then
  git checkout -b $TODAY
  git push origin $TODAY
  git checkout master
fi

Данный скрипт можно скачать или посмотреть с подсветкой синтаксиса на GitHub.

cd ~
wget https://raw.githubusercontent.com/netpoint-dc/configurations/master/syncer.sh
chmod 755 syncer.sh

Запуск скрипта осуществляется следующим образом:

bash /root/configurations/syncer.sh /root/configurations /etc /usr/local/etc

Для тестирования добавьте пользователя и выполните синхронизацию:

useradd testuser
bash /root/configurations/syncer.sh /root/configurations /etc /usr/local/etc

В репозитории должны быть соответствующие изменения. Теперь остается создать сценарий sync-configs в /etc/cron.hourly, выдать ему права 755 и убедиться в том, что он отрабатывает корректно:

#!/bin/bash
bash /root/configurations/syncer.sh /root/configurations /etc /usr/local/etc

Проверяем работоспособность:

chmod 755 /etc/cron.hourly/sync-configs
useradd testuser2
/etc/cron.hourly/sync-configs

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

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

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

Таким же образом Вы можете осуществлять и работу со вторичными данными, например, списком установленных в системе пакетов. Например, для Debian, Ubuntu:

dpkg --get-selections > /opt/system-info/packages.lst

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

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

Шаблон centos-7-x86_64-bitrixenv предназначен для быстрой и простой установки всего ПО, необходимого для работы продуктов и решений «1С-Битрикс» на платформе CentOS 7 x86_64.
Требуется виртуальный сервер тарифного плана не ниже Ferrum.
Более подробная информация доступна в нашей базе знаний centos-7-x86_64-bitrixenv

bandwidth.co.uk был их основным поставщиком, и Zare / Hydra Communications купили его




hydracom.co.uk
bgp.he.net/AS200039
zare.com/network

Лондон, Великобритания; Сегодня Hydra Communications Limited (22 июня 2018 года) завершила сделку по приобретению Bandwidth Technologies Limited, поставщика транзита, оптоволокна, колокейшн, baremetal-хостинга и управляемых услуг для нераскрытой суммы наличных денег. Экономия затрат на синергию между двумя компаниями поможет быстро расширить нашу линейку продуктов и повысить общее качество существующих и будущих услуг.

Приобретение расширит присутствие сети Hydra Communications до 6 мест в Европе; 5 в Лондоне и 1 в Амстердаме, подробно ниже. Помимо дополнительного офиса в Великобритании и добавления нескольких сотрудников в нашу постоянно растущую команду.

New Locations

• City Reach, London
• Telehouse North, London
• Equinix LD8, London
• Volta, London
• Digital Realty Sovereign House, London
• EvoSwitch, Amsterdam

New Exchanges

• LINX
• AMS-IX
• LONAP

Что мы можем ожидать в будущем?
Следующие изменения, обновления и дополнения будут внесены в ближайшие месяцы

• Baremetal, colocation, транзитные и оптоволоконные услуги, которые будут предлагаться в EvoSwitch, Амстердам.
• Настройка маршрутизатора N + N MX960 в City Reach, Лондон (основное место размещения безбортного места).
• Управляемые baremetal, брандмауэры и сетевые сервисы будут предлагаться во всех местах.
• Во всех местоположениях красные маршрутизаторы будут обновлены как минимум до MX480 или выше, а также как минимум 48-канальный блок DWDM MUX.
• AS200039 будет объединен в AS25369 и переименован в компанию HydraCom
• Порты Telia и Cogent будут добавлены в EvoSwitch, Амстердам, чтобы похвалить текущий порт AMS-IX + PNI
• Увеличенная кольцевая пропускная способность между Telehouse North, City Reach и LD8.
• Обновление существующей волны 10G между LD8, London и EvoSwitch, Амстердам
• Оптимизированные маршруты с низкой задержкой для Азии с использованием комбинации NTT, GTT и Telia + PNI
• Технологии Bandwidth LIR будут объединены в Hydra Communications LIR, добавив чуть менее 20 000 IP-адресов.
• Представляем Telecom Italia в нашем сетевом соединении в Лондоне.
• Диверсификация, когда T1 и PNI соединяются с нами в Лондоне (разделение на Telehouse North, Equinix LD8)

Рады сообщить о новой услуге: мы расширяем направление Private Cloud.

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

Почему бизнес выбирает Private Cloud?

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

Управлять своим облаком легко. Мы разворачиваем частное облако на базе открытого программного обеспечения OpenNebula. ПО используется во многих крупных внедрениях и хорошо зарекомендовало себя среди облачных провайдеров.

Больше о частном облаке читайте на нашем сайте: support.by/private-cloud/

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

Мы получили очень положительные отзывы во время предварительного просмотра, так сегодня, все облака всадники могут пользоваться функцией горячей снимок на виртуальных облачных серверов для резервного копирования своих томов в один клик, без каких-либо простоев.
Для того, чтобы облегчить и повысить свой опыт, мы также ввели новое действие сервера: Stop-In-Place. С помощью этого действия, сервер выключен, и все основные ресурсы остаются выделены для вас.

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

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