Часть первая. Вводная
Часть вторая. Настройка правил Firewall и NAT
Часть третья. Настройка DHCP
Часть четвертая. Настройка маршрутизации
Часть пятая. Настройка балансировщика нагрузки

Сегодня мы посмотрим на возможности настройки VPN, которые предлагает нам NSX Edge.

В целом мы можем разделить VPN-технологии на два ключевых вида:

• Site-to-site VPN. Чаще всего используется IPSec для создания защищенного туннеля, например, между сетью главного офиса и сетью на удаленной площадке или в облаке.
  
• Remote Access VPN. Используется для подключения отдельных пользователей к частным сетям организаций с помощью ПО VPN-клиента.

NSX Edge позволяет нам использовать оба варианта.
Настройку будем производить с помощью тестового стенда с двумя NSX Edge, Linux-сервера с установленным демоном racoon и ноутбука с Windows для тестирования Remote Access VPN.

Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».

Буду рассматривать следующие аспекты производительности виртуальных машин:

• CPU,
• RAM,
• DISK,
• Network.

Начну с CPU.

Для анализа производительности нам понадобятся:

• vCenter Performance Counters – счетчики производительности, графики которых можно посмотреть через vSphere Client. Информация по данным счетчикам доступна в любой версии клиента (“толстый” клиент на C#, web-клиент на Flex и web-клиент на HTML5). В данных статьях мы будем использовать скриншоты из С#-клиента, только потому, что они лучше смотрятся в миниатюре:)
• ESXTOP – утилита, которая запускается из командной строки ESXi. С ее помощью можно получить значения счетчиков производительности в реальном времени или выгрузить эти значения за определенный период в .csv файл для дальнейшего анализа. Далее расскажу про этот инструмент подробнее и приведу несколько полезных ссылок на документацию и статьи по теме.

PowerShell Desired State Configuration (DSC) сильно упрощает работу по развертыванию и конфигурированию операционной системы, ролей сервера и приложений, когда у вас сотни серверов.

Но при использовании DSC on-premises, т.е. не в MS Azure, возникает пара нюансов. Они особенно ощутимы, если организация большая (от 300 рабочих станций и серверов) и в ней еще не открыли мир контейнеров:

• Нет полноценных отчетов о состоянии систем. Если нужная конфигурация не применилась на каких-то серверах, то без этих отчетов мы об этом не узнаем. От встроенного сервера отчетов информацию получить довольно сложно, а для большого количества хостов – еще и долго.
• Отсутствует масштабируемость и отказоустойчивость. Невозможно построить ферму опрашивающих веб-серверов DSC, которые бы имели единую отказоустойчивую базу данных и общее хранилище mof-файлов конфигураций, модулей и ключей регистрации.

Сегодня я расскажу, как можно решить первую проблему и получить данные для построения отчетности. Все было бы проще, если в качестве базы данных можно было бы использовать SQL. MS обещает встроенную поддержку только в Windows Server 2019 или в build Windows server 1803. Забирать данные с использованием OleDB provider тоже не получится, так как DSC-сервер использует именованный параметр, который не полностью поддерживается OleDbCommand.

Нашел вот такой способ: тем, кто использует Windows Server 2012 и 2016, можно настроить использование БД SQL в качестве backend’a для опрашивающего DSC-сервера. Для этого создадим «прокси» в виде .mdb файла со связанными таблицами, который будет перенаправлять данные, полученные от отчетов клиентов, в БД SQL-сервера.

Часть первая. Вводная
Часть вторая. Настройка правил Firewall и NAT
Часть третья. Настройка DHCP
Часть четвертая. Настройка маршрутизации

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

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

Сегодня расскажу про две возможности Commvault для резервного копирования MS SQL, которые незаслуженно обходят стороной: гранулярное восстановление и плагин Commvault для SQL Management Studio.  Базовые моменты настройки рассматривать не буду. Пост скорее для тех, кто уже умеет устанавливать агент, настраивать расписание, политики и пр. О том, как устроен Commvault и что он умеет, рассказывал в этом посте.

Всем привет! Я руковожу центром киберзащиты DataLine. К нам приходят заказчики с задачей выполнения требований 152-ФЗ в облаке или на физической инфраструктуре.
Практически в каждом проекте приходится проводить просветительскую работу по развенчанию мифов вокруг этого закона. Я собрал самые частые заблуждения, которые могут дорого обойтись бюджету и нервной системе оператора персональных данных. Сразу оговорюсь, что случаи госконтор (ГИС), имеющих дело с гостайной, КИИ и пр. останутся за рамками этой статьи.

Часть первая. Вводная
Часть вторая. Настройка правил Firewall и NAT
Часть третья. Настройка DHCP

NSX Edge поддерживает статическую и динамическую (ospf, bgp) маршрутизацию.

Первоначальная настройка
Статическая маршрутизация
OSPF
BGP
Route Redistribution

Всем привет! Если вам регулярно приходится ломать голову над тем, как организовать ИТ-инфраструктуру, соответствующую 152-ФЗ, 187-ФЗ, PCI DSS и пр., то приходите на наш семинар 28 марта.

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

Дата и время: 28 марта, 10:30.
Место: Москва, Спартаковский переулок 2с1, подъезд №7, Пространство Весна
Спикеры: Василий Степаненко, директор центра киберзащиты DataLine, Дмитрий Никифоров, менеджер по развитию направления ИБ.

Многие клиенты, арендующие у нас облачные ресурсы, используют виртуальные Check Point’ы. С их помощью клиенты решают различные задачи: кто-то контролирует выход серверного сегмента в Интернет или же публикует свои сервисы за нашим оборудованием. Кому-то необходимо прогонять весь трафик через IPS blade, а кому-то хватает Check Point в роли VPN-шлюза для доступа к внутренним ресурсам в ЦОДе из филиалов. Есть и те, кому нужно защитить свою инфраструктуру в облаке для прохождения аттестации по ФЗ-152, но об этом я расскажу как-нибудь отдельно.

По долгу службы я занимаюсь поддержкой и администрированием Check Point'ов. Сегодня расскажу, что нужно учесть при разворачивании кластера из Check Point'ов в виртуальной среде. Затрону моменты уровня виртуализации, сети, настроек самого Check Point'а и мониторинга.
Не обещаю открыть Америку – многое есть в рекомендациях и best practices вендора. Но их же никто не читает), поэтому погнали.

Часть первая. Вводная
Часть вторая. Настройка правил Firewall и NAT

DHCP – сетевой протокол, позволяющий вашим виртуальным машинам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP.

В NSX Edge есть три опции настроек DHCP:

1. DHCP pool – создание пула адресов, которые будут выдаваться автоматически клиентам DHCP;
2. DHCP binding – привязка конкретного IP-адреса к определенному mac-адресу;
3. DHCP Relay – использование стороннего DHCP-сервера, выдающего IP-адреса серверам, которые находятся в других подсетях (отличных от DHCP-сервера).

Всем привет!

В ноябре мы запустили сервис по предоставлению и обслуживанию кластеров Kubernetes — KuberLine.

28 февраля мы расскажем, что такое Kubernetes и как его «готовить», чтобы от него была польза.
Будем рады видеть всех, кто уже хорошо знаком с контейнерами или только собирается открыть для себя этот «новый, дивный мир». Участие бесплатно, но нужно зарегистрироваться.

Дата и время: 28 февраля, 10:30.
Место: Москва, Спартаковский переулок 2с1, подъезд №7, Пространство Весна
Спикеры: Михаил Соловьев, R&D директор, Сергей Старицын, инженер Kubernetes.

Часть первая
После небольшого перерыва возвращаемся к NSX. Сегодня покажу, как настроить NAT и Firewall.

Зал дата-центра NORD-4 в 2016 году.

Вот пустой машинный зал в дата-центре. Думаете, стойку можно поставить в любое место? Если бы все было так просто!

Меня зовут Алексей, я занимаюсь capacity management в дата-центрах DataLine. Сегодня расскажу, что правильно расставлять стойки в зале – это целая наука, а иногда и искусство.

Что такое capacity management?

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

Если размещать оборудование как попало, то можем оказаться в следующих неприятных ситуациях:

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

2009	2019
Группа сети Дежурные инженеры Отдел эксплуатации инфраструктуры	Группа сети Группа виртуализации VMware Группа виртуализации Hyper-V Группа резервного копирования Группа Microsoft Группа мониторинга Группа Unix Группа DBA Центр киберзащиты Отдел управления внешними дата-центрами Дизайн-центр Отдел архитектурных решений Группа разработки ПО Отдел эксплуатации инфраструктуры Дежурные инженеры Служба технической поддержки

Небольшой филиал #10yearschallenge. Вот так выросла производственная дирекция.

Сегодня большинство клиентских кейсов задействуют компетенции 2-3 отделов производства. Например, у клиента пул ресурсов в облаке. Это уже два отдела – виртуализация и сеть.


Когда в проекте всего три отдела, скоординироваться не так сложно.

Это вторая часть введения в Kubernetes для пользователей VMware. Прежде чем перейти к практической части, ознакомьтесь с предыдущей статьей по ссылке.

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

Вот основные изменения:

• привязка Cloud Gateway к конкретным клиентам;
• репликация в организацию VMware vCloud Director. Раньше можно было делать реплики только на уровне vCenter. У клиентов не было возможности подключиться в реплике виртуальной машины через консоль, не проводя при этом failover.
• бэкап на ленты с привязкой клиента к конкретной ленте.

Подробности под катом.

Это вторая часть из моей серии постов “Kubernetes in the Enterprise”. Как я упоминал в моем последнем посте, очень важно при переходе к “Design and Implementation Guides” всем быть на одном уровне понимания Kubernetes (K8s).

Я не хочу здесь применять традиционный подход для объяснения архитектуры и технологий Kubernetes, а объясню все через сравнение с vSphere платформой, которая вам, как пользователям VMware, хорошо знакома. Это позволит вам преодолеть кажущуюся запутанность и тяжесть понимания Kubernetes. Я использовал этот подход внутри VMware для представления Kubernetes разным аудиториям слушателей, и он доказал, что отлично работает и помогает людям быстрее освоиться с ключевыми концепциями.

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