Tentang Planet, Region, Pod, Organisasi, Lingkungan, dan Host Virtual

Edge for Private Cloud v. 4.17.09

Penginstalan lokal Edge Private Cloud atau instance Edge terdiri dari beberapa Komponen edge diinstal pada serangkaian node server. Gambar berikut menunjukkan hubungan di antara planet, region, pod, organisasi, lingkungan, dan host virtual yang membentuk Instance edge:

Tabel berikut menjelaskan hubungan tersebut:

Tentang Planet

Planet mewakili seluruh lingkungan hardware dan software Edge serta dapat berisi satu atau beberapa region. Di Edge, planet adalah pengelompokan wilayah yang logis — Anda tidak secara eksplisit membuat atau mengonfigurasi sebuah planet sebagai bagian dari penginstalan Edge.

Tentang Wilayah

Region adalah pengelompokan dari satu atau beberapa pod. Secara {i>default<i}, saat Anda menginstal Edge, penginstal membuat satu region bernama "dc-1" yang berisi tiga pod, seperti tabel berikut menampilkan:

Gambar berikut menampilkan region default:

Gambar ini menunjukkan load balancer yang mengarahkan traffic ke "gateway" pod. "Gateway" tim berisi komponen Edge Router dan Message Processor yang menangani permintaan API. Kecuali Anda menetapkan beberapa pusat data, Anda tidak perlu membuat region tambahan.

Pada penginstalan yang lebih kompleks, Anda dapat membuat dua region atau lebih. Salah satu alasan untuk membuat beberapa region adalah mengatur mesin secara geografis, yang meminimalkan waktu transit jaringan. Di beberapa skenario ini, Anda menghosting endpoint API sehingga secara geografis "dekat" dengan konsumen API tersebut.

Di Edge, setiap wilayah disebut sebagai pusat data. Pusat data di Amerika Serikat Bagian Timur kemudian dapat menangani permintaan yang tiba dari Boston, Massachusetts, sementara pusat data di Singapura dapat menangani permintaan yang berasal dari perangkat atau komputer di Asia.

Misalnya, gambar berikut menunjukkan dua region, yang sesuai dengan dua pusat data:

Tentang Pod

pod adalah pengelompokan satu atau beberapa komponen Edge dan datastore Cassandra. Tepi komponen dapat diinstal pada {i>node<i} yang sama, tetapi biasanya diinstal pada {i>node<i} yang berbeda. Datastore Cassandra adalah repositori data yang digunakan oleh komponen Edge dalam pod.

Secara default, saat Anda menginstal Edge, penginstal akan membuat tiga pod dan mengaitkan berikut komponen Edge dan datastore Cassandra dengan setiap pod:

Komponen Edge dan datastore Cassandra di "gateway" pod diperlukan untuk API diproses. Komponen dan datastore ini harus aktif dan berjalan untuk memproses permintaan API. Tujuan komponen dan datastore di "pusat" dan "analitik" pod tidak diperlukan untuk memproses API, tetapi menambahkan fungsionalitas tambahan ke Edge.

Gambar berikut menampilkan komponen dalam setiap pod:

Anda bisa menambahkan pod Pemroses Pesan dan Router lain ke tiga pod yang dibuat oleh secara default. Atau, Anda dapat menambahkan komponen Edge tambahan ke pod yang ada. Misalnya, Anda dapat menambahkan {i>Router<i} dan Pemroses Pesan tambahan ke "{i>gateway<i}" untuk menangani peningkatan beban lalu lintas data.

Perhatikan bahwa "{i>gateway<i}" pod berisi komponen Edge Router dan Message Processor. Router hanya mengirim permintaan ke Pemroses Pesan di pod yang sama, bukan ke Pemroses Pesan di pod lainnya.

Anda bisa menggunakan panggilan API berikut untuk melihat detail pendaftaran server di akhir panggilan untuk setiap pod. Ini adalah alat pemantauan yang berguna.

curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=podName

dengan ms_IP adalah alamat IP atau nama DNS Server Pengelolaan, dan podName adalah:

• gateway
• pusat
• analytics

Misalnya, untuk "gateway" pod:

> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway

Anda akan melihat output dalam bentuk:

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
}, 
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

Atribut type mencantumkan jenis komponen. Perhatikan bahwa daftar Cassandra datastore yang terdaftar di pod. Sementara node Cassandra diinstal di "gateway" pod, Anda akan melihat datastore Cassandra yang terdaftar dengan semua pod.

Tentang Organisasi

Organisasi adalah penampung untuk semua objek di akun Apigee, termasuk API, produk API, aplikasi, dan developer. Sebuah organisasi dikaitkan dengan satu pod atau lebih, di mana setiap pod harus berisi satu atau beberapa Pemroses Pesan.

Dalam penginstalan Edge Private Cloud lokal, tidak ada organisasi secara default. Saat membuat organisasi, Anda menentukan dua informasi:

1. Pengguna yang berfungsi sebagai administrator organisasi. Kemudian, pengguna tersebut dapat menambahkan pengguna ke organisasi, dan menetapkan peran setiap pengguna.
2. "Gateway" pod, pod yang berisi Message Processors.

Sebuah organisasi dapat berisi satu atau beberapa lingkungan. Prosedur penginstalan Edge default meminta Anda untuk membuat dua lingkungan: "test" dan "prod". Namun, Anda dapat membuat lebih banyak yang diperlukan, seperti "staging", "eksperimen", dll.

Organisasi menyediakan cakupan untuk beberapa kemampuan Apigee. Misalnya, peta nilai kunci (KVM) data tersedia di tingkat organisasi, artinya dari semua lingkungan. Kemampuan lainnya seperti penyimpanan cache, dan cakupan untuk lingkungan tertentu. Data analisis Apigee dipartisi oleh gabungan dari organisasi dan lingkungan.

Di bawah ini adalah objek utama dari suatu organisasi, termasuk yang didefinisikan secara global dalam organisasi, dan grup yang didefinisikan khusus untuk suatu lingkungan:

Tentang Lingkungan

Lingkungan adalah konteks eksekusi runtime untuk proxy API di organisasi. Anda harus men-deploy proxy API ke lingkungan sebelum dapat diakses. Anda dapat men-deploy API {i>proxy<i} ke satu lingkungan atau ke beberapa lingkungan.

Sebuah organisasi dapat memiliki beberapa lingkungan. Misalnya, Anda dapat mendefinisikan "dev", "test", dan "prod" lingkungan dalam suatu organisasi.

Saat membuat lingkungan, Anda mengaitkannya dengan satu atau beberapa Pemroses Pesan. Anda dapat pikirkan sebuah lingkungan sebagai serangkaian {i> Message Processor<i} di mana {i>proxy<i} API berjalan. Setiap dapat dikaitkan dengan Pemroses Pesan yang sama, atau dengan yang berbeda.

Untuk membuat lingkungan, tentukan dua informasi:

1. Organisasi yang mencakup lingkungan.
2. Pemroses Pesan yang menangani permintaan proxy API ke lingkungan. Pesan Ini Pemroses harus berada dalam pod yang terkait dengan organisasi induk lingkungan.
   Secara default, saat Anda membuat lingkungan, Edge mengaitkan semua Pemroses Pesan yang tersedia di "gateway" pod dengan lingkungan. Atau, Anda dapat menentukan subset dari tersedia di Pemroses Pesan sehingga Pemroses Pesan yang berbeda dapat menangani permintaan ke lingkungan fleksibel App Engine.

Pemroses Pesan dapat dikaitkan dengan beberapa lingkungan. Misalnya, Edge Anda penginstalan berisi dua Pemroses Pesan: A dan B. Anda kemudian membuat tiga lingkungan di organisasi: "dev", "test", dan "prod":

• Untuk "dev" Anda mengaitkan Pemroses Pesan A karena Anda tidak mengharapkan volume lalu lintas yang besar.
• Untuk "pengujian" lingkungan, Anda mengaitkan Pemroses Pesan B karena Anda tidak mengharapkan volume lalu lintas yang besar.
• Untuk "prod" Anda mengaitkannya, baik Pemroses Pesan A maupun B, untuk menangani volume tingkat produksi.

Pemroses Pesan yang ditetapkan ke suatu lingkungan bisa berasal dari pod yang sama, atau bisa berasal dari beberapa pod, yang mencakup beberapa region dan pusat data. Misalnya, Anda menentukan lingkungan "global" di organisasi Anda yang mencakup Pemroses Pesan dari tiga region, yang berarti tiga pusat data yang berbeda: Amerika Serikat, Jepang, dan Jerman.

Men-deploy proxy API ke "global" menyebabkan proxy API berjalan pada Message Prosesor di ketiga pusat data. Traffic API yang tiba di Router di salah satu pusat data akan diarahkan hanya ke Pemroses Pesan di pusat data tersebut karena {i>Router<i} hanya mengarahkan traffic ke Pemroses Pesan di pod yang sama.

Tentang Host Virtual

Host virtual menentukan port di Router Edge tempat proxy API diekspos, dan, dengan demikian, URL yang digunakan aplikasi untuk mengakses proxy API. Setiap lingkungan harus mendefinisikan setidaknya satu {i>host<i} virtual.

Pastikan nomor port yang ditentukan oleh host virtual terbuka di node Router. Anda dapat lalu akses proxy API dengan membuat permintaan untuk:

http://<routerIP>:<port>/{proxy-base-path}/{resource-name}
https://<routerIP>:<port>/{proxy-base-path}/{resource-name}

dalam hal ini:

• http atau https: Jika host virtual dikonfigurasi untuk mendukung TLS/SSL, gunakan HTTPS. Jika host virtual tidak mendukung TLS/SSL, gunakan HTTP.
• &lt;routerIP&gt;:&lt;port&gt; adalah IP alamat dan nomor porta dari {i>host<i} virtual.
• {proxy-base-path} dan {resource-name} telah ditentukan saat Anda membuat proxy API.

Biasanya, Anda tidak memublikasikan API kepada pelanggan dengan alamat IP dan nomor port. Sebagai gantinya, Anda menentukan entri DNS untuk {i>Router<i} dan porta. Contoh:

http://myAPI.myCo.com/{proxy-base-path}/{resource-name}
https://myAPI.myCo.com/{proxy-base-path}/{resource-name}

Anda juga harus membuat alias {i>host<i} untuk {i>host<i} virtual yang cocok dengan nama domain DNS entri. Dari contoh di atas, Anda akan menentukan alias host myAPI.myCo.com. Jika Anda tidak memiliki entri DNS, atur alias host ke alamat IP {i>Router<i} dan porta host virtual, sebagai &lt;routerIP&gt;:port.

Untuk informasi selengkapnya, lihat Tentang host virtual (Beta).

Setelah membuat organisasi pertama Anda, lingkungan, dan {i>host<i} virtual

Setelah menyelesaikan proses penginstalan Edge, tindakan pertama Anda biasanya adalah membuat organisasi, lingkungan, dan {i>host<i} virtual melalui "orientasi" {i>checkout<i}. Untuk melakukan orientasi, jalankan perintah berikut pada node Edge Management Server:

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

Perintah ini mengambil file konfigurasi sebagai input yang mendefinisikan pengguna, organisasi, lingkungan, dan {i>host<i} virtual.

Misalnya, Anda membuat:

• Pengguna yang Anda pilih untuk berfungsi sebagai administrator organisasi
• Organisasi bernama example
• Lingkungan di organisasi bernama prod yang dikaitkan dengan semua Pesan Prosesor di "gateway" tim
• Host virtual di lingkungan bernama default yang mengizinkan akses HTTP pada port 9.001
• Alias host untuk host virtual

Setelah menjalankan skrip tersebut, Anda dapat mengakses API menggunakan URL dalam formulir:

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

Anda nanti dapat menambahkan sejumlah organisasi, lingkungan, dan host virtual.

Untuk informasi selengkapnya tentang orientasi, lihat Melakukan aktivasi organisasi/pengaturan.