In an edge computing environment, control over where your instances are placed is everything. Being able to locate workloads closer to the user implies a physical affinity direction relative to the user, and thus some way to model that in the infrastructure, as well as some way to direct workloads accordingly. In OpenStack, that is done with Availability Zones.
Historically, availability zones were used in monolithic datacenter deployments to define boundaries between dependent systems. Ideally this provided a way for API users to place workloads on compute nodes that did not share critical resources, such as power, cooling, and networking. The important piece of data for placing an edge workload is more about the geography or distance from a user, but the fundamental idea is the same: choosing a group of resources that share some common attribute. Indeed, an edge site will also very likely not share many physical resources with another, being separated by some non-trivial distance compared to a monolithic datacenter arrangement.
The infrastructure setup must be done as an admin at setup time or when adding new compute nodes. Assume for the sake of discussion that we have the following sites:
-
A central-datacenter with two nodes hostA and hostB
-
An edge site called 'edge-east' with two compute nodes, hostC and hostD
-
An edge site called 'edge-west' with two compute nodes, hostE and hostF
The best practice here would be to configure three availability zones, one for each of the three sites we have. Further, the default AZ should generally be set to the central datacenter zone, so that any
instance booted without specifically targeting one of our edge sites will be placed in the datacenter. Currently, the compute services at the edge must host instances with ephemeral storage. The high level architectural view of this example looks like figure 1:
Figure 1: A high-level overview of an edge computing setup
Site Availability Zone Setup
First, we will create the three zones. Note that availability zones are special instances of host aggregates, so the commands we use for administering zones are actually for aggregates. The steps are:
$ openstack aggregate create central --zone central $ openstack aggregate create east --zone east $ openstack aggregate create west --zone west
In most cases, instances should be directed to specific edge sites as needed. Conversely, instances that do not need to be at an edge site should land on a host in the central datacenter, where capacity is larger. To make sure that instances not targeted to a particular edge site are sent to the central datacenter, we need to configure Nova with:
[DEFAULT] default_schedule_zone = central
In order to get director to do this for you, create a director environment file with the following and add to the deploy command line:
parameter_defaults: ControllerExtraConfig: nova::availability_zone::default_schedule_zone: central controller_classes: - ::nova::availability_zone
NOTE: If, for some reason it is desirable to force all instance boots to specify a zone, it is possible to create an empty zone and set that as the default. Doing so will cause the user to receive a message indicating that the default zone is “not available” without starting the instance build. This may be useful for cases where all capacity is at the edge sites, with no general central datacenter with capacity for untargeted workloads.
Next we need to assign our compute nodes to the proper zone so that the scheduler knows where they are located and how to answer requests for specific areas.
$ openstack aggregate add host central hostA $ openstack aggregate add host central hostB $ openstack aggregate add host east hostC $ openstack aggregate add host east hostD $ openstack aggregate add host west hostE $ openstack aggregate add host west hostF
To check that the hosts are mapped properly, check the state of each aggregate and verify that the availability_zone
is set, and that the relevant hosts are listed. For example, the central aggregate should look like this:
$ openstack aggregate show central +-------------------+----------------------------+ | Field | Value | +-------------------+----------------------------+ | availability_zone | central | | created_at | 2019-01-30T14:52:10.000000 | | deleted | False | | deleted_at | None | | hosts | [u'hostA'. u’hostB’] | | id | 1 | | name | central | | properties | | | updated_at | None | +-------------------+----------------------------+
Now that all of that is configured, we can boot some instances targeted at specific sites. First, we will boot an instance with no destination set, which should land in the central datacenter:
$ openstack server create --flavor tiny --image rhel test1
Check that the availability zone of this server was forced to be central:
$ openstack server show -f value -c OS-EXT-AZ:availability_zone -c OS-EXT-SRV-ATTR:host test1 central hostA
Next, we will boot an instance specifically to run at the 'east' edge site:
$ openstack server create --flavor tiny --image rhel --availability-zone east test2
Which should land on either hostC or hostD to satisfy the requirement for being in the 'east' availability zone. Confirm that the host and zone are correct for this as well:
$ openstack server show -f value -c OS-EXT-AZ:availability_zone -c OS-EXT-SRV-ATTR:host test2 east hostC
If you’d like to learn more about Red Hat’s edge computing approach, we invite you to visit "Understanding edge computing."
저자 소개
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.