[CONN] Add Default Region/Zone to Connection and Allow API Calls to Specify Target Zone

[powerkimhub]

@seokho-son @dogfootman @dev4unet @zephy-mzc

[현황]

• Connection은 Region 뿐만 아니라, 특정 Zone 수준까지 지정/고정하여 등록 및 활용
• Connection 중심으로 자원 생성/관리로 Connection간 독립적으로 자원이 관리되고 있음
• 단일 Connection 기반으로 inter-Zone HA 구성 등 2개 이상의 Zone 활용이 불가함
  • 예시) AWS K8S Cluster 생성시 최소 2개 Zone의 subnet 구성 필수인데, 서로 다른 zone의 subnet을 구성/설정할 수 없음
    • => AWS K8S Cluster 생성 불가
• WebTool 연결 정보 관리 대상에서 Zone 정보 제외 계획 중임
  • But, 현재 Connection 관리 구조로는 적용하기 어려움

[계획]

• 고려사항: 기존 Connection 관리 방식 호환 유지(backward compatibility)
• 가급적 Driver 변경 없이 Sever 계층에서 기능 확장 (필요시 Driver 기능 최소 확장)
• 기존 사용자가 Region 정보로 등록한 Zone을 Default Zone으로 처리하고,
• API 호출 시에 인자로 Zone을 선택 가능하도록 기능 확장
• 자원 생성 Spider API 호출과 Zone 선정 관계
  • (1) API 호출시 Target Zone 입력 값이 없을 경우: Connection에 설정된 Region Info에 사전 설정된 Default Zone에 자원을 생성
  • (2) API 호출시 Target Zone 입력 값이 존재할 경우: 사용자가 API 인자로 입력한 Zone에 자원을 생성
  • (3) CSP가 자체 스케줄링에 의해 선정 하도록, CSP Random Zone에 자원을 생성
    • 하위 호환성 및 Random 지정을 제공하지 않는 CSP 존재(사용자 항시 Zone 지정) 등을 고려하여 현재는 (3)은 제외
  • 일단, (1), (2) 옵션을 제공
• Create/List/Get API 반환 정보에 Region, Zone 정보 추가 제공

[Task]

• ■ Server 적용
  • Default Zone 개념 추가 및 API 호출 시 사용자 Zone 인자 기반 요청 처리 기능 추가
  • 필요시, Spider Meta 정보에 자원별 Region, Zone 정보 관리 추가(필요성 재검토 필요)
• ■ Rest API 적용 및 필요시 API 추가
• ■ AdminWeb 적용

[powerkimhub]

[Zone-Level 제어 현황 분석]

• 자원 중에는 Region 대상으로 생성/삭제 가능한 자원과,
• Zone 대상으로 생성/삭제가 가능한 자원이 존재함
• 이를 분류하기 위하여 다음과 같이 드라이버 수준에서 자원별 Zone 설정 여부를 분석함
  • https://docs.google.com/spreadsheets/d/1L5No_Bk6EAFQmeErTV5yb-vBfBeTjb6h/edit#gid=989504448

[분석 결과]

• 현재 제공하는 Driver 기준으로 공통적으로 Zone-Level 제어가 가능한 자원은
• 다음과 같이 3가지 자원임(일부 CSP는 약간 다를 수 있음)
  • (1) Subnet
  • (2) VM
  • (3) Disk

[자원별 제공 방안]

• (1) Subnet

  • 하나의 VPC 생성시에 여러개의 Subnet 생성 요청이 가능하며,
    • 이때 Subnet별로 다른 Zone에 생성 요청이 가능하도록 지원
  • 생성시: VPC/Subnet 생성시 요청 정보 SubnetInfo[]에 Subnet별로 Zone 정보 추가
    • 모든 Driver 반영 필요: Subnet 생성 요청시 입력된 Zone 위치에 생성 요청
    • 대상 API: CreateVPC(), AddSubnet()
  • 조회시: Subnet 반환 정보 SubnetInfo[]에 Subnet별로 Zone 정보 추가
    • 모든 Driver 반영 필요
    • 대상 API: ListVPC(), GetVPC()

• (2) VM: 변경 불필요

  • 생성시: 기존 API는 VM 생성 시 Subnet 정보를 입력 받음,
    • Subnet 정보와 Zone 정보는 일대일 관계이며, Subnet 정보로 Zone 정보를 대신할 수 있음
  • 조회시: 기존 VM 반환 정보에 이미 RegionInfo가 포함, RegionInfo에는 Region과 Zone ID가 포함됨

• (3) Disk

  • 생성시: Disk 생성시 요청 정보 DiskInfo에 Zone 정보 추가
    • 모든 Driver 반영 필요: Disk 생성 요청시 입력된 Zone 위치에 생성 요청
    • 대상 API: CreateDisk()
  • 조회시: Disk 반환 제공 DiskInfo 정보에 Zone 정보 추가
    • 대상 API: ListDisk(), GetDisk(), AttachDisk()

[Updated Task]

• All Driver 적용
  • VPCHandler 및 DiskHandler 반영
  • 추가된 Zone 변수 입력이 nil 또는 ""이면, 전과 동일한 처리
  • 입력 info의 Zone 변수가 설정되어 있으면 설정된 Zone에 생성 처리
• Server 적용
  • Default Zone 개념 추가 및 API 호출 시 사용자 Zone 인자 기반 요청 처리 기능 추가
  • 필요시, Spider Meta 정보에 자원별 Zone 정보 관리 추가(반영시 필요성 재검토 필요)
• Rest API 변경 적용
• AdminWeb 변경 적용

[powerkimhub]

[Driver Common Interface 반영]

• VPCHandler
  

  cb-spider/cloud-control-manager/cloud-driver/interfaces/resources/VPCHandler.go

  Line 30 in 2610c22

  Zone string // Target Zone Name

• DiskHandler
  

  cb-spider/cloud-control-manager/cloud-driver/interfaces/resources/DiskHandler.go

  Line 28 in 2610c22

  Zone string // Target Zone Name

[powerkimhub]

[Driver 반영 현황]

• AWS
• Azure
• GCP
• Alibaba
• Tencent
• IBM VPC
• OpenStack
• NHN
• NCP Classic
• NCP VPC
• KT Classic
• KT VPC

[MZC-CSC]

Driver Interface의 struct는 수정이 되어있으나
api-runtime의 req struct는 수정이 되어있지 않은 것 같습니다.

확인바랍니다.

api-runtime > VPC-SubnetRest.go

// 144Line
type vpcCreateReq struct {
ConnectionName string
ReqInfo struct {
Name string
IPv4_CIDR string
SubnetInfoList []struct {
Name string
IPv4_CIDR string
Zone string -----------> 여기 추가 필요
}
}
}

func CreateVPC 에서 173Line
for _, info := range req.ReqInfo.SubnetInfoList {
subnetInfo := cres.SubnetInfo{IId: cres.IID{info.Name, ""}, IPv4_CIDR: info.IPv4_CIDR, Zone: info.Zone} ----------> 여기 추가 필요
subnetInfoList = append(subnetInfoList, subnetInfo)
}

func AddSubnet 에서 349Line
reqSubnetInfo := cres.SubnetInfo{IId: cres.IID{req.ReqInfo.Name, ""}, IPv4_CIDR: req.ReqInfo.IPv4_CIDR, Zone: req.ReqInfo.Zone} ---------------> 여기 추가 필요

[powerkimhub]

@MZC-CSC

• 넵, 확인/공유 캄사드립니다.
• 반영시 참고하도록 하겠습니다.

[MZC-CSC]

@powerkimhub
api-runtime > DiskRest.go 도 동일합니다.
type DiskReq struct 에 Zone 추가
func CreateDisk 의 reqInfo에 Zone 추가

추가로 attach의 경우에는 동일한 zone끼리 작업하는 것으로 봐야할까요?
disk의 경우 생성시점에는 zone이 특정되나 attach의 인자에서는 zone을 안받는 것 같습니다.
func AttachDisk 는 zone을 받지 않고 disk의 IID와 vm의 IID를 받고있습니다.

aws의 경우 volume와 vm이 동일 zone끼리만 attach됩니다.
1안 vm과 attach하려는 disk의 zone을 각각 조회하여 같은 zone이면 attach하도록 처리해야 할까요?
2안 동일 zone일 경우 attach가 되므로 다른 zone이면 오류가 나는 것이 맞다. -> 변경 필요 없음.

이부분도 확인 바랍니다.

[powerkimhub]

@MZC-CSC

• 아, 일단 Driver 수준 시험 후 PR 부탁 드립니다.
• Zone-Level 제어 관련 Server/RESTAPI/AdminWeb 반영 필요하며, 아직 계획 상태입니다.
• 먼저 올려 주시면, 서버파트 개발시에 몇 개의 Driver에 대해서는 제가 통합 시험 진행하도록하겠습니다.

[powerkimhub]

추가로 attach의 경우에는 동일한 zone끼리 작업하는 것으로 봐야할까요? disk의 경우 생성시점에는 zone이 특정되나 attach의 인자에서는 zone을 안받는 것 같습니다. func AttachDisk 는 zone을 받지 않고 disk의 IID와 vm의 IID를 받고있습니다.

aws의 경우 volume와 vm이 동일 zone끼리만 attach됩니다. 1안 vm과 attach하려는 disk의 zone을 각각 조회하여 같은 zone이면 attach하도록 처리해야 할까요? 2안 동일 zone일 경우 attach가 되므로 다른 zone이면 오류가 나는 것이 맞다. -> 변경 필요 없음.

이부분도 확인 바랍니다.

• Disk --> VM Attach의 경우,
• ID만으로 CSP에 요청을 보내면 될 것 같습니다.
• Zone이 달라서 paring이 맞지 않을 경우, CSP가 에러를 반환하니 그때 올려주시면 될 것으로 보입니다.

[powerkimhub]

@MZC-CSC

• Server, Rest API, AdminWeb을 반영하였습니다. (c3d13af)
• AWS:Subnet 통합 시험을 완료했습니다.
• AWS:Disk 정보의 경우,
  • 통합 시험시 Zone 정보가 올라오지 않아 다음과 같이 반영 후 통합 시험을 완료 하였습니다.
    • 5565c6d
  • 관련하여, 추가 확인할 부분 등 점검 부탁 드립니다.

[MZC-CSC]

--

현재 DB의 구조가
connection , iid 만 저장하고 있습니다.
저장을 다른 zone을 했을 때는
connection + iid 자체가 다른 zone을 조회할 수 없는 구조입니다.

ListDisk를 해당 region의 zone들을 조회해서 zone들의 disk목록을 합치도록 하려고 했으나 ListDisk() 자체가 사용되지 않는 듯하고
GetDisk에서 region내 zone들에 iid로 조회하는 것은 불필요한 작업이 많지 않나 하는 생각이 듭니다.

Zone단위인 경우에는 다음 방법 중 하나를 사용해야 할 것 같습니다.

1. GetDisk에서 region내 zone들에 iid 로 조회
2. CreateDisk에서 connection 및 zone 도 함께 저장 -> GetDisk 할 때 connection과 zone으로 대상 zone 설정 후 대상 zone에 iid로 조회

[powerkimhub]

@MZC-CSC

• 의견 캄사드립니다.

[ListXXX()를 유지하는 사유]

• 의견 주신 바와 같이,
• 현재 Spider 서버에서는 Driver의 ListXXX()를 사용되고 있지 않지만, 추후 사용할 가능성이 커서 유지 하고자 합니다.
• 초기에는 Driver:List()를 사용하여 Driver 반환 목록에서 Spider를 통해서 생성한 자원들만 filtering 해서 반환하는 형태로 제공했었습니다.
• 이 방법은 SG나 KeyPair와 같이 전체 목록은 많고, 현재 Spider에서 생성한 자원이 몇개 안될때는 비효율적이라고 생각 되었으며, 현재 동일 자원이 많이 생성/관리 되지 않는 시점에는 Driver:Get()을 순회하여 제공하고 있습니다.
• 하지만, 이 방법은 Spider가 생성한 자원이 많아 질수록 반복적인 CSP Call이 증가하고(Call Limit 위협), 점차 느려진다는 단점이 있습니다.
• 추후에는 자원이 특정 갯수 이상일 때는 Dirver:List()를, 이하일 때는 Driver:Get()을 사용하는 등 혼합된 형태를 고려하고 있습니다.

[GetDisk(): Zone 인자 추가 관련]

• 기존 자원 API와의 일관성을 유지하는데 너무 집중했나 봅니다^^

• 어차피 Zone-Level 제어라는 차이가 있으므로, API가 좀 달라도 문제가 없을 것 같습니다.

• Create/List를 제외하고, DiskHandler를 다음처럼 개선하면 되겠지요?

  • AS-IS

        GetDisk(diskIID IID) (DiskInfo, error)
        ChangeDiskSize(diskIID IID, size string) (bool, error)
        DeleteDisk(diskIID IID) (bool, error)
    
        //------ Disk Attachment
        AttachDisk(diskIID IID, ownerVM IID) (DiskInfo, error)
        DetachDisk(diskIID IID, ownerVM IID) (bool, error)
    

  • TO-BE

        GetDisk(diskIID IID, zone String) (DiskInfo, error)
        ChangeDiskSize(diskIID IID, size string, zone String) (bool, error)
        DeleteDisk(diskIID IID, zone String) (bool, error)
    
        //------ Disk Attachment
        AttachDisk(diskIID IID, ownerVM IID, zone String) (DiskInfo, error)
        DetachDisk(diskIID IID, ownerVM IID, zone String) (bool, error)
    

• 혹시, Subnet 관련해서는 특이 사항이 없는지요?

[MZC-CSC]

Subnet 관련해서
region기반의 csp는 해당 region + iid 를 했을 때 정상적으로 가져올 수 있기 때문에 문제가 없습니다.
zone 기반의 csp는 connection과 다른 zone에 생성하게 되면 Get 할 때 동일한 문제가 있습니다.
get할 때 connection + iid 로 조회하기 때문에 zone이 다르면 조회가 되지 않습니다.

[MZC-CSC]

GCP 확인결과
subnet은 region base 였습니다.
disk와 동일할 것이라고 생각했는데
subnet은 생성자체를 region까지만 바라보고 있습니다.

그래서 GCP의 subnet은 zone의 영향을 받지 않습니다.

참고바랍니다.

https://cloud.google.com/compute/docs/reference/rest/v1/subnetworks/insert

[powerkimhub]

@MZC-CSC @inno-cloudbarista @ish-hcc @innodreamer

[From Slack: Message by @MZC-CSC]
disk_iid_infos table에 zone column이 추가되는 방법은 어떤지요?
DiskHandlerconnection을 설정할 때 내부에서 zone만 추가로 매핑하도록 설정하면 GetDisk나 다른 function들도 수정할 필요가 없을 것 같은데
connection에서 zone이 빠지더라도 실제 zone은 table에 저장된 zone을 사용하므로 영향도도 적을 것 같습니다.

  * 위 제안 주신 방법을 기반으로 최종 아래와 같이 정리하였습니다. 
  * 아래 API별 가이드 참고하시어 추진 부탁 드립니다.
  * 진행에 이슈가 생기시면 남겨주시기 바랍니다. 
  * 통합 시험은 위쪽 [AdminWeb 기반 Test 방법] 참고하시기 바랍니다.

[Subnet]

• CreateVPC()/AddSubnet()
  • 입력 받은 ReqInfo에 포함된 SubnetInfo.Zone 정보를 사용하여 대상 Zone에 생성 요청
• 그외 API
  • Subnet은 VPC에 매달린 상태이므로, VPC 정보 등을 활용하여 Subnet의 Zone 정보 획득하여 처리

[Disk]

• CreateDisk()
  • 입력 받은 ReqInfo에 포함된 Zone 정보를 사용하여 대상 Zone에 생성 요청
• ListDisk()
  • Region 단위로 list를 제공하는 CSP
    • CSP가 반환하는 Region의 모든 Disk 정보를 제공
  • Zone 단위로 list를 제공하는 CSP
    • (1) 대상 Region의 사용 가능한 Zone 목록을 획득
    • (2) Zone별 Disk List 획득 후 통합하여 반환
    • ※ 현재, 서로 다른 Zone에 동일 ID의 Disk가 생성되지는 않습니다.
• 그외 API

  • 최신 버전을 받으시면, Driver Interface에 다음과 같이 TagetZone이 추가되었습니다.

    cb-spider/cloud-control-manager/cloud-driver/interfaces/CloudDriver.go

    Line 65 in 2567c1f

    TargetZone string // Used for Zone-Level Control(Ex. DiskHandler)

  • GetDisk() 등 API 구현 시에 다음과 같이 TargetZone을 활용하셔서 처리하시기 바랍니다. (Create/List는 위 가이드 참고)

    func (DiskHandler *AwsDiskHandler) GetDisk(diskIID irs.IID) (irs.DiskInfo, error) {	
        fmt.Printf("==GetDisk : %s, %s, %s\n", DiskHandler.Region.Region, DiskHandler.Region.Zone, DiskHandler.Region.TargetZone)
    

[MZC-CSC]

참고
GCP의 경우 Disk가 zone 기반이어서 문제가 있었으나
Subnet은 Region 기반이어서 영향을 받지 않습니다.

[MZC-CSC]

@powerkimhub

Disk 조회시
region의 zone 과 targetZone이 있어서
targetZone != "" 이면 targetZone을 활용하라는 말씀이죠?

아래 사항도 검토 바랍니다.

CloudDriverHandler_common.GetZoneLevelCloudConnection -> commonGetCloudConnection 으로 connection 정보를 가져오는데
commonGetCloudConnection 안에서 target zone으로 connectin을 반환하면 뒤쪽로직의 변경이 필요없습니다.
// Change Zone
if connectionInfo.RegionInfo.TargetZone != "" {
cblog.Info("change Zone ", connectionInfo.RegionInfo.Zone, " To ", connectionInfo.RegionInfo.TargetZone)
connectionInfo.RegionInfo.Zone = connectionInfo.RegionInfo.TargetZone
}

[powerkimhub]

@MZC-CSC

Disk 조회시 region의 zone 과 targetZone이 있어서 targetZone != "" 이면 targetZone을 활용하라는 말씀이죠?

• 넵, 맞습니다.

아래 사항도 검토 바랍니다.

CloudDriverHandler_common.GetZoneLevelCloudConnection -> commonGetCloudConnection 으로 connection 정보를 가져오는데 commonGetCloudConnection 안에서 target zone으로 connectin을 반환하면 뒤쪽로직의 변경이 필요없습니다. // Change Zone if connectionInfo.RegionInfo.TargetZone != "" { cblog.Info("change Zone ", connectionInfo.RegionInfo.Zone, " To ", connectionInfo.RegionInfo.TargetZone) connectionInfo.RegionInfo.Zone = connectionInfo.RegionInfo.TargetZone }

• 제안 방법 캄사드립니다.

• 제안 주신 방법은 초기 Driver 코드 변경 없이 Server 변경으로만 추진하고자 진행했었던 PoC 방안이었습니다.

• PoC 방법과 달리, TargetZone 변수 추가로 변경한 사유는 다음과 같습니다.

  • Driver 수준에서 동일한 변수(RegionInfo.Zone)에 2가지 의미(default Zone or target Zone)를 부여할 경우
    • 추후 또는 제 3자에게 코드 이해에 혼돈을 야기시킬 수 있을 거라 생각했습니다.
  • 또한, 추후 Zone-Level 자원 추가 시 Driver 수준에서 default Zone과 target Zone 값을 둘다 알아야 할 경우가 생긴다면,
    • 다시 개선 작업이 필요하게 될 거라 생각했습니다.
    • 이런 활용 사례가 없을 수도 있지만,
    • 기본적으로는 하나의 변수를 서로 다른 의미로 공유 활용하는 것은 회피하고자 합니다.

• 참고: 초기 PoC 코드 블록(desiredZone == TargetZone)

      if desiredZone != "" {
    	  if zoneName == "" {
    		  return nil, fmt.Errorf(cloudConnectName + ": The region " + regionName + " does not support zone")
    	  } else {
    		  zoneName = desiredZone
    	  }
      }
  
      connectionInfo := idrv.ConnectionInfo{ // @todo powerkim
    	  CredentialInfo: idrv.CredentialInfo{
    		  ClientId:         getValue(crdInfo.KeyValueInfoList, "ClientId"),
  
                          ... 중략 ...
  
    	  },
    	  RegionInfo: idrv.RegionInfo{ // @todo powerkim
    		  Region:        regionName,
    		  Zone:          zoneName,
    		  ResourceGroup: getValue(rgnInfo.KeyValueInfoList, "ResourceGroup"),
    	  },
      }

[MZC-CSC]

[Tencent] 소스는 이전 PR에 포함되어 있어서 이미 적용되어 있습니다.

issue_1067 gcp: set zone for subnet, disk #1155

[powerkimhub]

[Tencent] 소스는 이전 PR에 포함되어 있어서 이미 적용되어 있습니다.

issue_1067 gcp: set zone for subnet, disk #1155

• 관련 시험 결과 확인 부탁드립니다.
• #1179

[innodreamer]

@powerkimhub KT Cloud Classic의 경우, disk 정보 조회시 정보에 zone 정보를 포함할 수 있지만, disk 생성시 zone을 지정할 수 있는 parameter가 존재해도 해당 connection의 zone에 대해서만 disk를 생성할 수 있습니다.
다른 zone을 선택해서 disk를 생성할 경우 request 정보가 잘못되었다고 CSP error가 발생합니다.

[powerkimhub]

@innodreamer

• 관련하여, 다음 링크 참고해주시기 바랍니다.
• [Azure] Fixed zone control issue #1311 (comment)

[innodreamer]

@powerkimhub KT Cloud Classic의 경우, StartVM() 실행시 KeyPair의 경우도 Target zone에서 생성해놓은 KeyPair를 적용해야 VM 생성이 진행되는데 AdminWeb UI에서 VM 생성 위해 설정시 KeyPair의 경우 다른 zone에서 생성한 KeyPair는 나타나지 않는 문제가 있습니다.
(참고, KOR-Seoul-M2 zone은 driver 내 client API call URL이 아예 달라서 tag를 포함한 모든 자원에 대해 zone을 구분해야 하는 거 같습니다.)

[innodreamer]

@powerkimhub 자원 정보 listing 할때 해당 region 내 모든 zone의 자원을 보여주면 위의 문제가 해결될거 같기도 하네요.
시도해보겠습니다.

[powerkimhub]

@innodreamer

• KeyPair가 Zone-based로 관리되나 보네요.
  • Spider는 KeyPair의 경우 현재 Zone-based가 아닌데요.
  • 모든 Zone의 KeyPair를 제공한다 해도, 현재 KeyPair 정보에는 Zone 정보를 제공하고 있지 않기 때문에,
  • 사용자가 A-Zone의 KeyPair를 B-Zone의 VM에 설정할 수도 있고,
  • 이 경우, 사용자 입장에서는 예상치 못한 오류를 받게 될 것입니다.

• 혹시, SecurityGroup, NLB도 Zone-based로 관리되는지요?
  • 모든 자원이 Zone-based로 관리된다면,
  • Spider 입장에서 개념적으로 Region으로 봐야 할지 고민이 필요해 봐야 할 것 같습니다.

[powerkimhub]

• v0.10.2에 반영 및 시험 완료
• 참고: Zone‐based Control Guide