Vcf vmware что это
In this post, which I am planning to be the first of a number of posts on VCF version 3.9, I am going to go through the initial deployment of the management domain. However before we get into that, we need to spend a little time to understand some of the basic architectural components of VCF.
Зачем нужна сертификация VMware Ready
Начнем с того, что сертификация VMware Ready означает высокий уровень одобрения для продуктов, созданных партнерами компании VMware. Нетрудно догадаться, что Kingston Digital входит в их число: в частности, является членом “Партнерского технологического альянса VMware”. Участники этого альянса разрабатывают свои устройства в соответствии со стандартами VMware и предоставляют их техническим специалистам компании, которые проводят различные сертификационные тесты.
По итогам проверок, сервера, компьютеры, устройства хранения и другие устройства, отвечающие сертификационным требованиям, получают заветный логотип VMware Ready. Кроме того, в дальнейшем эти продукты поддерживаются как со стороны компании-партнера, так и со стороны VMware. Подробную информацию о твердотельных накопителях Kingston из линейки, которые прошли сертификацию VMware можно найти и на портале VMware Solution Exchange (VSX). Там же размещаются обновления ПО для пользователей “железа” сертифицированного VMware.
Возвращаясь к “Партнерскому технологическому альянсу VMware”, стоит упомянуть о том, что участие в нем позволяет клиентам быстро находить сертифицированное оборудование партнеров, не занимаясь точечным и индивидуальным подбором компонентов, которые в итоге могут не обеспечить ожидаемую производительность. Не в последнюю очередь это способствует росту продаж накопителей Kingston. Только за первое полугодие 2019 года компании удалось реализовать более 13,3 миллиона твердотельных накопителей (по исследованиям TrendFocus). Если говорить о глобальных поставках, хорошие продажи обеспечили Kingston третье место в списке лидеров по реализации SSD-накопителей после Samsung и Western Digital.
SDDC successfully deployed – woot!
All going well, and if no further issues are encountered, you will now have your full SDDC up and running. The cloud builder will provide you with a link to the SDDC Manager and you are now ready to start creating workload domains. It should look something like the screenshot below.
And here is the SDDC that was deployed, as seen from the vSphere client. We can see the 4 ESXi nodes, the NSX Manager and 3 controllers (Node entries). We see the vCenter with 2 x External PSCs (Platform Service Controllers), a 3 node Log Insight Cluster and the SDDC Manager. The cloud builder (vcf-cb-01) can now be removed as it has served its purpose.
There are some other steps that we should now do. One of these is the roll-out of some additional vRealize products such as vRealize Operations and vRealize Automation. Then we can take a look at the Workload Domains, and rollout workload domains for other virtual infrastructures, Horizon View or even PKS. I’ll try to get to those soon. We will look at these is some future posts.
Если посмотреть конфиг любого файрвола, то, скорее всего, мы увидим простыню с кучей IP-адресов, портов, протоколов и подсетей. Так классически реализуются политики сетевой безопасности для доступа пользователей к ресурсам. Сначала в конфиге стараются поддерживать порядок, но потом сотрудники начинают переходить из отдела в отдел, сервера размножаться и менять свои роли, появляются доступы для разных проектов туда, куда им обычно нельзя, и получаются сотни неизвестных козьих тропок.
Около каких-то правил, если повезет, прописаны комментарии «Попросил сделать Вася» или «Это проход в DMZ». Сетевой администратор увольняется, и все становится совсем непонятно. Потом кто-то решил почистить конфиг от Васи, и упал SAP, потому что когда-то Вася просил этот доступ для работы боевого SAP.
Сегодня я расскажу про решение VMware NSX, которое помогает точечно применять политики сетевого взаимодействия и безопасности без неразберихи в конфигах файрвола. Покажу, какие новые функции появились по сравнению с тем, что было раньше у VMware в этой части.
VMWare NSX – платформа виртуализации и обеспечения безопасности сетевых сервисов. NSX решает задачи маршрутизации, коммутации, балансировки нагрузки, файрвола и умеет много другого интересного.
NSX – это преемник собственного продукта VMware vCloud Networking and Security (vCNS) и приобретенного Nicira NVP.
Leave a Reply Cancel reply
Типы виртуализации VMware
Все программы для виртуализации можно разделить на пять типов: серверная виртуализация, виртуализация десктопов, сетевая виртуализация, виртуализация хранилищ и ПО для управления облачными средами. О виртуализации в серверной среде мы уже немного рассказали выше, а вот что подразумевается под остальными типами?
Виртуализация десктопов и облачные среды
Виртуализация десктопов, которую иногда называют инфраструктурой виртуальных десктопов (VDI), — это такой тип виртуализации, при котором ОС настольных ПК работает как виртуальная машина на физическом сервере с другими виртуальными десктопами. Обработка нескольких виртуальных рабочих мест происходит на одном или нескольких физических серверах, обычно – в централизованном ЦОД. Копия ОС и приложений, которые использует каждый конечный пользователь, обычно кэшируется в памяти, как один образ на физическом сервере.
Пакет VMware Horizon позволяет организациям запускать рабочие столы Windows в центре обработки данных или в облачных сервисах на базе VMware Cloud, что устраняет необходимость размещения и управления десктопами с офисного рабочего места, централизует управление пользовательской средой и обеспечивает ее безопасность.
Сетевая виртуализация
При развертывании данного типа виртуализации используется ПО для выполнения сетевых функций путем отделения виртуальных сетей от базового сетевого оборудования. Как только вы начнете использовать виртуализацию сети, физическая сеть будет использоваться только для пересылки пакетов, поэтому все управление осуществляется с помощью виртуальных или программных коммутаторов. Поставщиками сетевой виртуализации являются внутренние виртуальные коммутаторы гипервизора. Кроме того, сторонние поставщики, такие как Cisco и IBM, разработали виртуальные коммутаторы, которые могут использоваться гипервизорами, такими как ESXi.
Виртуализация хранилищ
Как мы уже отмечали, для каждого типа виртуализации компания VMware предлагает определенный набор софта. Например, если мы говорим о хранении данных, то следует принимать во внимание такие решения, как VMware vSAN и VMware Site Recovery Manager (SRM). VMware vSAN — программная функция хранения, встроенная в гипервизор ESXi и интегрированная с vSphere. Она объединяет дисковое пространство от нескольких хостов ESXi и выделяет его с помощью интеллектуальных политик, таких как ограничения защиты, тонкое выделение ресурсов и кодирование стирания. А еще эта опция интегрируется с функцией vSphere High Availability, обеспечивая повышенную производительность вычислений и самого хранилища.
VMware Site Recovery Manager (SRM) предназначен для управления аварийным восстановлением, что позволяет администраторам создавать планы восстановления, которые автоматически выполняются в случае сбоя, а также автоматически организовывать аварийное переключение и восстановление виртуальных машин. SRM также интегрируется с VMware NSX (инструмент управления сетевыми операциями) для сохранения сетевых политик и политик безопасности на виртуальных машинах, перемещенных на новые физические сервера.
Management Domain
A management domain is used to host the infrastructure components needed to instantiate, manage, and monitor the Cloud Foundation infrastructure. The management domain is automatically created using the Cloud Builder appliance when it is initially configured.
A management domain requires 4 ESXi nodes. It also only leverages vSAN for storage. Thus vSAN is the required principal storage for any VCF management domain.
Размеры NSX Edge
В зависимости от решаемых задач и объемов VMware рекомендует создавать NSX Edge следующих размеров:
NSX Edge (Compact) | NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
vCPU | 1 | 2 | 4 | 6 |
Memory | 512MB | 1GB | 1GB | 8GB |
Disk | 512MB | 512MB | 512MB | 4.5GB + 4GB |
Назначение | Одно приложение, тестовый дата-центр | Небольшой или средний дата-центр | Нагруженный файрвол | Балансировка нагрузки на уровне L7 |
Ниже в таблице – рабочие метрики сетевых служб в зависимости от размера NSX Edge.
NSX Edge (Compact) | NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
Interfaces | 10 | 10 | 10 | 10 |
Sub Interfaces (Trunk) | 200 | 200 | 200 | 200 |
NAT Rules | 2,048 | 4,096 | 4,096 | 8,192 |
ARP Entries Until Overwrite | 1,024 | 2,048 | 2,048 | 2,048 |
FW Rules | 2000 | 2000 | 2000 | 2000 |
FW Performance | 3Gbps | 9.7Gbps | 9.7Gbps | 9.7Gbps |
DHCP Pools | 20,000 | 20,000 | 20,000 | 20,000 |
ECMP Paths | 8 | 8 | 8 | 8 |
Static Routes | 2,048 | 2,048 | 2,048 | 2,048 |
LB Pools | 64 | 64 | 64 | 1,024 |
LB Virtual Servers | 64 | 64 | 64 | 1,024 |
LB Server / Pool | 32 | 32 | 32 | 32 |
LB Health Checks | 320 | 320 | 320 | 3,072 |
LB Application Rules | 4,096 | 4,096 | 4,096 | 4,096 |
L2VPN Clients Hub to Spoke | 5 | 5 | 5 | 5 |
L2VPN Networks per Client/Server | 200 | 200 | 200 | 200 |
IPSec Tunnels | 512 | 1,600 | 4,096 | 6,000 |
SSLVPN Tunnels | 50 | 100 | 100 | 1,000 |
SSLVPN Private Networks | 16 | 16 | 16 | 16 |
Concurrent Sessions | 64,000 | 1,000,000 | 1,000,000 | 1,000,000 |
Sessions/Second | 8,000 | 50,000 | 50,000 | 50,000 |
LB Throughput L7 Proxy) | 2.2Gbps | 2.2Gbps | 3Gbps | |
LB Throughput L4 Mode) | 6Gbps | 6Gbps | 6Gbps | |
LB Connections/s (L7 Proxy) | 46,000 | 50,000 | 50,000 | |
LB Concurrent Connections (L7 Proxy) | 8,000 | 60,000 | 60,000 | |
LB Connections/s (L4 Mode) | 50,000 | 50,000 | 50,000 | |
LB Concurrent Connections (L4 Mode) | 600,000 | 1,000,000 | 1,000,000 | |
BGP Routes | 20,000 | 50,000 | 250,000 | 250,000 |
BGP Neighbors | 10 | 20 | 100 | 100 |
BGP Routes Redistributed | No Limit | No Limit | No Limit | No Limit |
OSPF Routes | 20,000 | 50,000 | 100,000 | 100,000 |
OSPF LSA Entries Max 750 Type-1 | 20,000 | 50,000 | 100,000 | 100,000 |
OSPF Adjacencies | 10 | 20 | 40 | 40 |
OSPF Routes Redistributed | 2000 | 5000 | 20,000 | 20,000 |
Total Routes | 20,000 | 50,000 | 250,000 | 250,000 |
Из таблицы видно, что балансировку на NSX Edge для продуктивных сценариев рекомендуется организовывать, только начиная с размера Large.
На сегодня у меня все. В следующих частях подробно пройдусь по настройке каждой сетевой службы NSX Edge.
Привет, Хабр! Сегодня мы поговорим о виртуальных машинах, программном обеспечении VMware и накопителях Kingston, конечно же. В частности, разберем вопросы на тему “зачем нужна сертификация VMware Ready, какие из SSD-решений получают статус VMware Ready for Storage, и о чем это говорит?”. Начнем с самого банального.
Безусловно, аудитории Хабра знакома компания VMware, которая занимается разработкой программного обеспечения для виртуализации и организации облачных вычислений. Продукты VMware включают в себя средства виртуализации, управления сетью и безопасностью, программное обеспечение для ЦОД и хранения данных.
Первым таким продуктом стала программа VMware Workstation, которая позволяла любому пользователю установить на своем ПК одну или несколько виртуальных машин: то бишь имитацию аппаратной начинки компьютера в лице процессора, видеокарты, накопителей, оптических приводов и т.д. Эдакий компьютер в компьютере.
В рамках серверной среды VMware Workstation вкупе с установленным гипервизором VMware ESX позволяет запускать несколько виртуальных машин на одном физическом сервере, при этом каждая из ВМ может работать со своей операционной системой. Следовательно — на одном сервере могут быть активными сразу несколько разных ОС.
При этом все установленные ВМ совместно используют доступные ресурсы (сетевую карту и оперативную память), но работают независимо друг от друга. Основными продуктами в этом направлении является платформа VMware vSphere, гипервизор VMware ESX и VMware ESXi, VMware Server и vCenter Server. Впрочем, серверная виртуализация — не единственный тип абстрагирования от аппаратной реализации.
Cloud Builder in action
I am going to deploy VCF 3.9 in this example. We start with the cloud builder. The cloud builder is a single use appliance provided by VMware. The deployment is not much different from many other vSphere appliances. Simply deploy the OVA, populate the appropriate fields and once the deployment completes, users connect to a cloud builder URL to continue the deployment. Once logged in using credentials provided during the appliance roll-out, admins are presented with a Pre-bringup checklist. All of these tasks need to be validated before continuing. For those considering deploying VCF, please spend a lot of time validating this checklist. It will save you a lot of time and effort later on in the deployment process, as it is not easy to modify the configuration after the roll-out has commenced. In may cases, you may need to clean up the parts that have already been deployed and start over. Therefore spending some cycles ensuring this checklist is valid for your environment will be beneficial in the long run.
And now we come to the guts of the cloud builder. Admins are provided with a sample configuration file/parameter sheet which must be populated with information pertinent to the Software Defined Data Center (SDDC) that they wish to deploy.
- ESXi hosts
- vCenter Server
- vSAN
- NSX
- SDDC Manager
- vRealize Log Insight
The information that needs to be populated includes license information, host and appliance passwords, networking information (VLAN, IP addresses, Gateways, MTUs), as well as SSH RSA Key Fingerprints and SSL Thumbprints (SHA1) for the ESXi hosts.
NSX requires additional information for the NSX Manager and the 3 NSX Controllers that are deployed. vRealize Log Insight is deployed as a 3 node cluster, so requires IP addresses and hostnames as well as an additional Load-Balancer IP address and hostname. Here are a few sample pages from the configuration parameters that needs to populated. DNS resolution of hostnames is also key. Below is the management workloads page where licenses for the various components are populated.
Another page in the configuration relates to the ESXi hosts that make up the management domain. You need to also include VLAN information and IP addresses for the vMotion network and vSAN network, as you can see below.
The fingerprint and thumbprint from each ESXi host is also required. I’ll show you some tips on how to capture those shortly. This may seem like a lot of information, but the spreadsheet is actually quite straight forward to populate. Once the parameter sheet is filled, simply upload it to the cloud builder:
Once the parameter file has been uploaded, it will be validated by the cloud builder. Since I was deploying this in my lab, the validation reported a number of warnings. For production deployments, all of these should be examined and addressed so that the status reports Success is all cases.
What is very neat is that every step of the way, you are shown exactly what activity is taking place. Here is the very start of the bring-up from my lab environment.
For more detailed information, the debug log of the bring-up can be referenced.
Now, as you can well imagine, there are a lot of steps to standing up an SDDC. The screenshot above is only a small snippet of everything that is deployed and configured. But the whole point is that this is now completely automated, saving you a whole bunch of time, effort and in a lot of cases, pain. I was very pleasantly surprised with how quickly I was able to roll out an SDDC on my 4 lab ESXi nodes, once I gained some level of familiarity with cloud builder and how to populate the parameter sheet.
Что нового у NSX Edge?
Функциональность NSX Edge зависит от редакции NSX. Всего их пять: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Все новое и интересное можно увидеть только начиная с Advanced. В том числе и новый интерфейс, который до полного перехода vCloud на HTML5 (VMware обещает лето 2019-го) открывается в новой вкладке.
Firewall. В качестве объектов, к которым будут применяться правила, можно выбрать IP-адреса, сети, интерфейсы шлюза и виртуальные машины.
DHCP. Помимо настройки диапазона IP-адресов, которые будут автоматически выдаваться виртуальным машинам этой сети, в NSX Edge стали доступны функции Binding и Relay.
Во вкладке Bindings можно привязать MAC-адрес виртуальной машины к IP-адресу, если нужно чтобы IP-адрес не менялся. Главное, чтобы этот IP-адрес не входил в DHCP Pool.
Маршрутизация. У vShield Edge можно было настраивать только статическую маршрутизацию. Здесь появилась динамическая маршрутизация с поддержкой протоколов OSPF и BGP. Также стали доступны настройки ECMP (Active-active), а значит и аварийное переключение типа «активный-активный» на физические маршрутизаторы.
Настройка OSPF
Настройка BGP
Еще из нового – настройка передачи маршрутов между различными протоколами,
перераспределение маршрутов (route redistribution).
Также во вкладке Application Rules теперь можно добавлять скрипты, которые будут напрямую управлять балансировкой трафика.
VPN. В дополнение к IPSec VPN, NSX Edge поддерживает:
- L2 VPN, позволяющий растянуть сети между географически разнесенными площадками. Такой VPN нужен, например, чтобы при переезде на другую площадку виртуальная машина оставалась в той же подсети и сохраняла IP-адрес.
- SSL VPN Plus, который позволяет пользователям подключаться удаленно к корпоративной сети. На уровне vSphere такая функция была, а вот для vCloud Director это новшество.
Группы объектов (Grouping Objects). В этой вкладке как раз задаются группы объектов, для которых будут действовать те или иные правила сетевого взаимодействия, например правила файрвола.
Этими объектами могут быть IP- и MAC-адреса.
Здесь также указан список сервисов (сочетание протокол-порт) и приложений, которые можно использовать при составлении правил файрвола. Новые сервисы и приложения добавлять может только администратор портала vCD.
Статистика. Статистика по подключениям: трафик, который проходит через шлюз, файрвол и балансировщик.
Статус и статистику по каждому туннелю IPSEC VPN и L2 VPN.
Логирование. Во вкладке Edge Settings можно задать сервер для записи логов. Логирование работает для DNAT/SNAT, DHCP, Firewall, маршрутизации, балансировщика, IPsec VPN, SSL VPN Plus.
Для каждого объекта/сервиса доступны следующие типы оповещений:
— Debug
— Alert
— Critical
— Error
— Warning
— Notice
— Info
Какие SSD-накопители обладают статусом VMware Ready
Применительно к накопителям Kingston серверного класса, сертификацию VMware Ready for Storage имеют твердотельные SATA-накопители Kingston DC500R и Kingston DC500M, рекомендованные для использования в ЦОД. Как мы уже отметили выше, присвоенный данным SSD-решениям статус говорит о том, что DC500R и DC500M получили полное одобрение от специалистов VMware, успешно пройдя все тесты.
Именно эта сертификация позволяет представителям Kingston Digital говорить о том, что при использовании SSD DC500R и DC500M в среде vSAN и серверах vSphere можно ожидать высокой производительности при выполнении большого количества операций чтения данных и смешанных нагрузках. К слову, для прохождения сертификации серверные накопители настраиваются в соответствии с требованиями от VMware и в итоге обеспечивают высокую пропускную способность, кол-во IPOS, а также минимальную задержку в 99% сценариев.
Как итог: сертифицированные SSD Kingston с чистой совестью можно отнести к классу высокопроизводительных ускорителей для виртуализированных рабочих нагрузок смешанного типа в рамках серверной среды. Также они позволяют облачным службам работать с максимальной эффективностью и предоставляют пользователям очень быстрый доступ к данным. Собственно, от них это и требуется.
Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
You may ask, “Why is this such a big deal”? With Cloud Foundation, your management domain requires vSAN, which can easily be managed using policy-based management or SPBM. SPBM allows simplified operational management of your storage capabilities. Although you can use tag-based policies with external storage for Cloud Foundation, it is not something that scales easily and requires quite a bit of manual operations. When you think about the possible scale Cloud Foundation enables, manually tagging datastores can become daunting. Subsequently, being able to programmatically manage all your VCF storage simplifies your operations, freeing valuable time for other tasks.
In Cloud Foundation 4.0 we supported vSAN, NFS, and VMFS on FC for Principal Storage for newly created Workload Domain clusters. Cloud Foundation 4.1 expands Principal Storage options by adding support for vVols. vVols was previously supported for Supplemental Storage only. The big difference between the two is Principal Storage is the initial storage option selected when creating new clusters in Cloud Foundation, the setup of principal storage is automated through Cloud Foundation workflows. Supplemental storage is added to a cluster manually through the vSphere Web UI after it has been created. With vVols, numerous benefits may now be utilized in Cloud Foundation and, you can use the same SPBM management plane for your vSAN and external arrays. vVols enables you to use all of your array’s capabilities such as array-based snapshots, cloning, and replication. All managed via policies, on a single vVols datastore, with VM granularity.
The Cloud Foundation engineering team has been diligently working internally and with our storage partners to enable vVols as principal storage. With the 4.1 release, we support NFS 3.x, FC, and limited iSCSI protocols for vVols. For iSCSI, there are a few pre-tasks that must be completed. Setting up your SW iSCSI initiator on all your hosts in the new WLD, and your VASA must be listed as a Dynamic Target.
The VASA registration has been enabled outside the workflow in the event incorrect VASA details are entered. This way, the workflow doesn’t fail, allowing you to update incorrect information for the VASA registration.
Once you get to the storage for the new WLD, you can enter the details for the vVols datastore.
After going through the rest of the details for the new WLD, you will see we now have vVols storage.
With the WLD build completed, you can then go into your hosts, and you will see a vVols datastore connected to the hosts.
As a default, an SPBM policy, “vVols No Requirement Policy,” is created. We do not create any other SPBM policies because there are too many variables between array types and customer requirements. There is no way to generate an advanced policy, tailored to the requirements needed, without input from the customer. This allows the customer to create specific and tailored SPBM policies that meet application, organization, or security requirements.
To learn more about VCF and vVols, make sure to attend Todd Simmons and my VMworld session.
VCF and vVols: Empower Your External Storage [HCI2270]
Be sure to check out the VCF announcement blog.
What’s New with VMware Cloud Foundation 4.1
More VMworld sessions
vSphere 7 U1 storage related blogs
Jason Massae
Jason is the vVols and Core Storage Staff Technical Marketing Architect for VMware. Focusing on vSphere vVols and Core Storage technologies as well as working with VMware's storage partners to…
VMware Cloud Foundation(VCF) is VMware’s integrated SDDC platform for private and hybrid cloud infrastructures. This software package integrates VMware’s Compute, Storage and Network Virtualization solutions with a centralized automated lifecycle management tool call SDDC Manager. The core components of VCF are vSphere (Compute), vSAN (Storage) and NSX (Network & Security). VMware vRealize Suite can also be optionally added to VCF to increase the capability of SDDC infrastructure with performance & capacity Management and cloud management. Since VCF 3.8 beside running normal virtual machine workloads, you can also run containers with use of VMware Enterprise PKS.
To start implementing VCF at least seven ESXi hosts is needed, four for Management Workload Domain(WLD) which hosts infrastructure components of SDDC and another three host for running actual infrastructure WLD. These nodes can be vSAN ready nodes or you can take advantage of DellEMC’s VxRAIL platform and run more integrated Hyper-converged(HCI) platform. The Management WLD brought up with use of special virtual appliance call Cloud Builder. This awesome tool brings up four first nodes in management cluster alongside Platform Service Controllers(PSC), vCenter Servers, NSX manager & controllers and vRealize Log Insight. After the initial bring up process VCF infrastructure management will be done through SDDC Manager.
One concept that catch attentions of those who just started to work with VCF is Workload Domain(WLD). WLD is being used by VCF to group-together resources which contains host clusters and most possibly vSAN datastore. Earlier release of VCF each Workload domain could hold only one cluster but since VCF 3.0, each WLD can hold multiple host clusters. Initially WLD is also unit of lifecycle management in VCF and when the available upgrade packages are being applied to the WLD as a whole. The only exception is from VCF 3.9 individual host cluster can be life cycled for ESXi upgrades. This means that if you there is multi cluster WLD in place, every cluster can proceed with ESXi upgrades individually.
In terms of storage, vSAN is the only storage solution that can be used in Management WLD. For VI, Horizon and PKS WLDs, VCF use vSAN as a principal preferred storage solution but, since VCF 3.5, NFS datastores and, since VCF 3.9, Fibre Channel systems can be used for storage consumption. But because of storage policy flexibility and compatibility with rest of VMware’s products, it is highly recommended to use VMware vSAN as the storage solution for VCF.
Another aspect of VCF that provides value for customers is ease of Day 2 operations like lifecycle management and password-related operations. When there are various inter-related products that has been deployed into SDDC environment, it is always hard to execute upgrade projects. It can be super complex to define the inter-operable version and also update sequence. With use of VCF, upgrading SDDC environment is fully automated and orchestrated and the responsible team does not need to worry the upgrade process. It is just a matter of having the right packages downloaded into SDDC Manager’s repository and execute the upgrade in each WLD.
In terms of password management, SDDC Manager is a central location that stores all administration password that is related to VMware SDDC environment. This is very important not just for ease of administration but also to make sure if a password changes, it get updated on all related systems. Password Management page of SDDC Manager can be used to update or automatically rotate password for accounts that are tracked in SDDC Manager.
As it mentioned before, vRealize Suite can be implemented through SDDC Manager. vRealize Log Insight(vRLI) is the only product that is being deployed through the bring-up process but enabled and licensed only for Management WLD. In addition to vRLI, vRealize Operations(vROPS) and vRealize Automation(vRA) can also be deployed through SDDC Manager. One thing that should kept in mind is vRealize Suite Lifecycle Manager (vRSLCM) should be deployed prior to starting vROPS or vRA.
In series of blog posts in VCF section, we will discuss various topics related to VMware Cloud Foundation deployment and administration.
Workload Domains
Workload Domains provide an integrated selection of compute, storage and network resources for business workloads to run in. These are a logical abstraction of resource, provisioned automatically by SDDC (Software Defined Data Center) Manager, and administered and patched independently. VCF provides a fully automated process for creating, extending, and deleting workload domains using SDDC Manager. Hosts and clusters may also be removed from a workload domain to reduce its size.
Workload domains require a minimum of 3 ESXi hosts and can leverage vSAN storage (default and preferred), but it can also consume secondary storage in the form of NFS 3.x datastores (since VCF 3.5) and Fibre Channel Storage (since VCF 3.9).
A user will have one primary/principal storage but could have additional secondary storage. This is a topic for another day.
Some useful tips
(a) Fingerprints and Thumbprints
When filling out the parameter sheet, you are asked to provide both the SSH Fingerprint and SSL Thumbprint. While this information is available in the DCUI of each ESXi host, it is a PITA to go around to each console to retrieve this info. My good pal William has details on how to get the SSL thumbprint on his site here, but what about the SSH fingerprint?
This command (taken from William) when run on the ESXi host will give you the SSL Thumbprint:
This command when run from a host that has ssh-keyscan, will give you the SSH Fingerprint:
(b) No eligible capacity disks found
In this example, the bringup failed because it said there were no capacity disks available for vSAN. The actual real cause was the fact that there was a combination of flash devices in one of the hosts, not just the two types expected for the cache tier and the capacity tier. The answer was in KB 54793. When configuring an all-flash host for use with VMware Cloud Foundation for Service Providers, ensure that there are no more than two types or sizes of flash drive. I was able to work around this by simply formatting the additional flash devices (not required for vSAN) with VMFS-6. Retrying the bringup picked up where it left off, which is a nice feature. Kudos to my buddy Paudie for that tip.
(c) Ensure you have the correct licenses
While this is unlikely to happen in customer environments, it might be an issue for those of you with home labs. I noticed an issue with licenses when my hosts failed to join the distributed switch:
The only other issues I hit were (a) selecting the wrong VLAN for my vSAN network and (b) having a duplicate IP address on my network which I had assigned to the Log insight Load Balancer (both of these were my own fault). Fortunately, I was able to fix the VLAN issue by logging into the management vCenter and correcting the VLAN ID on the distributed portgroup for the vSAN network. I also tracked down the duplicate IP (a K8s service) and took it off the network, allowing the Log Insight Load Balancer configuration to complete.
This is a good lesson on getting everything right up front. These were easy enough to address, but there is no way to modify the configuration after deployment. If you use the wrong IP address for something, you will probably have to delete everything that was created and start again. So the lesson is, double-check and treble check your parameter file before doing a bringup.
Cloud Builder
The Cloud Builder is a virtual appliance provided by VMware, and is used to deploy and configure the VCF management domain, and once that task is completed, it transfers control over to the SDDC Manager.
Cloud Builder
The Cloud Builder is a virtual appliance provided by VMware, and is used to deploy and configure the VCF management domain, and once that task is completed, it transfers control over to the SDDC Manager.
От vCNS к NSX
Раньше у клиента в облаке, построенном на VMware vCloud, была отдельная виртуальная машина vCNS vShield Edge. Он выполнял роль пограничного шлюза, где можно было настроить множество сетевых функций: NAT, DHCP, Firewall, VPN, балансировщика нагрузки и пр. vShield Edge ограничивал взаимодействие виртуальной машины с внешним миром согласно правилам, прописанным в Firewall и NAT. Внутри сети виртуальные машины общались между собой свободно в пределах подсетей. Если очень хочется разделять и властвовать трафиком, можно сделать отдельную сеть для отдельных частей приложений (разных виртуальных машин) и прописать в файрволе соответствующие правила по их сетевому взаимодействию. Но это долго, сложно и неинтересно, особенно когда у вас несколько десятков виртуальных машин.
В NSX VMware реализовала концепцию микросегментации с помощью распределенного файрвола (distributed firewall), встроенного в ядро гипервизора. В нем прописываются политики безопасности и сетевого взаимодействия не только для IP- и MAC-адресов, но и для других объектов: виртуальных машин, приложений. Если NSX развернут внутри организации, то такими объектами могут стать пользователь или группа пользователей из Active Directory. Каждый такой объект превращается в микросегмент в своем контуре безопасности, в нужной подсети, со своей уютненькой DMZ :).
Раньше периметр безопасности был один на весь пул ресурсов, защищался пограничным коммутатором, а с NSX можно оградить от лишних взаимодействий отдельную виртуальную машину даже в пределах одной сети.
Политики безопасности и сетевого взаимодействия адаптируются, если объект переезжает в другую сеть. Например, если мы перенесем машину с базой данных в другой сетевой сегмент или даже в другой связанный виртуальный дата-центр, то правила, прописанные для этой виртуальной машины, продолжат действовать безотносительно ее нового положения. Сервер приложений по-прежнему сможет взаимодействовать с базой данных.
На смену самому пограничному шлюзу vCNS vShield Edge пришел NSX Edge. У него есть весь джентльменский набор старого Edge плюс несколько новых полезных функций. Про них и пойдет речь дальше.
SDDC Manager
Once the management domain has been configured by cloud builder, control and management passes to the SDDC Manager. From here, a multitude of tasks can be carried out, such as the creation of workload domains such as Virtual infrastructure WLDs, Horizon WLDs and PKS WLDs in the 3.9 version of VCF. You can also commission new ESXi hosts for use in WLDs, manage new Composable Infrastructure from both DELL (MX series) and HPE (Synergy series) and deploy the a vRealize Suite (i.e. vRealize Operations and vRealize Automation).
About the Authors
Sadaf Allahyari & Shahrouz Lahiji are Data Center & Cloud specialists. Both are double VCIX on Data Center & Network virtualization, vExperts and also VMUG leaders in Sweden.
Читайте также: