درباره سیارات، مناطق، غلاف ها، سازمان ها، محیط ها و میزبان های مجازی

Edge for Private Cloud نسخه 4.17.05

یک نصب در محل Edge Private Cloud یا یک نمونه Edge، شامل چندین مؤلفه Edge است که روی مجموعه‌ای از گره‌های سرور نصب شده‌اند. تصویر زیر رابطه بین سیاره، مناطق، پادها، سازمان‌ها، محیط‌ها و میزبان‌های مجازی را نشان می‌دهد که یک نمونه Edge را تشکیل می‌دهند:

جدول زیر این روابط را توضیح می دهد:

حاوی

مرتبط با

پیش فرض

سیاره

یک یا چند منطقه

n/a

منطقه

یک یا چند غلاف

"dc-1"

غلاف

یک یا چند جزء Edge

"مرکزی"
"دروازه"
"تحلیل"

سازمان

یک یا چند محیط

یک یا چند غلاف حاوی پردازشگر پیام و کاربری که به عنوان سرپرست سازمان عمل می کند

هیچ کدام

محیط زیست

یک یا چند میزبان مجازی

یک یا چند پردازشگر پیام در غلاف مرتبط با سازمان مادر

هیچ کدام

میزبان مجازی

یک یا چند نام مستعار میزبان

هیچ کدام

درباره سیاره ها

سیاره یک محیط سخت افزاری و نرم افزاری کامل Edge را نشان می دهد و می تواند شامل یک یا چند منطقه باشد. در Edge، یک سیاره یک گروه بندی منطقی از مناطق است - شما به طور صریح یک سیاره را به عنوان بخشی از نصب Edge ایجاد یا پیکربندی نمی کنید.

درباره مناطق

منطقه گروهی از یک یا چند غلاف است. به طور پیش فرض، هنگامی که Edge را نصب می کنید، نصب کننده یک منطقه واحد به نام "dc-1" حاوی سه پاد ایجاد می کند، همانطور که جدول زیر نشان می دهد:

منطقه

غلاف در منطقه

"dc-1"

"دروازه"، "مرکزی"، "تحلیلی"

تصویر زیر مناطق پیش فرض را نشان می دهد:

این تصویر بار متعادل کننده را نشان می دهد که ترافیک را به غلاف "دروازه" هدایت می کند. پاد "دروازه" شامل مولفه های Edge Router و Message Processor است که درخواست های API را مدیریت می کند. مگر اینکه چندین مرکز داده را تعریف کنید، نباید مناطق اضافی ایجاد کنید.

در یک نصب پیچیده تر، می توانید دو یا چند منطقه ایجاد کنید. یکی از دلایل ایجاد چندین منطقه، سازماندهی جغرافیایی ماشین‌ها است که زمان انتقال شبکه را به حداقل می‌رساند. در این سناریو، شما نقاط پایانی API را میزبانی می‌کنید تا از نظر جغرافیایی به مصرف‌کنندگان آن APIها نزدیک باشند.

در Edge، هر منطقه به عنوان مرکز داده نامیده می شود. سپس یک مرکز داده در شرق ایالات متحده می‌تواند به درخواست‌های ارسالی از بوستون، ماساچوست رسیدگی کند، در حالی که یک مرکز داده در سنگاپور می‌تواند درخواست‌هایی را که از دستگاه‌ها یا رایانه‌های آسیایی می‌آیند رسیدگی کند.

به عنوان مثال، تصویر زیر دو منطقه مربوط به دو مرکز داده را نشان می دهد:

درباره Pods

پاد گروهی از یک یا چند مولفه Edge و ذخیره‌گاه داده Cassandra است. اجزای Edge را می توان روی یک گره نصب کرد، اما معمولاً روی گره های مختلف نصب می شوند. دیتا استور Cassandra یک مخزن داده است که توسط اجزای Edge در پاد استفاده می شود.

به طور پیش‌فرض، وقتی Edge را نصب می‌کنید، نصب‌کننده سه پاد ایجاد می‌کند و اجزای Edge زیر و داده‌های Cassandra را با هر پاد مرتبط می‌کند:

غلاف

اجزای لبه

انبارهای داده کاساندرا

"دروازه"

روتر، پردازشگر پیام

حافظه پنهان داده
ضد داده
dc-datastore

keyvaluemap-datastore
kms-datastore

"مرکزی"

سرور مدیریت، Zookeeper، LDAP، UI، Qpid

برنامه-دادگاه
apimodel-datastore
حسابرسی-دادگاه
auth-datastore

شناسه-دادگاه
edgenotification-datastore
مدیریت-سرور
زمانبندی-ذخیره داده
user-settings-datastore

"تحلیل"

Postgres

تجزیه و تحلیل-دادگاه

Reportcrud-datastore

اجزای Edge و داده‌های Cassandra در پاد "دروازه" برای پردازش API مورد نیاز هستند. این مؤلفه‌ها و ذخیره‌سازی داده‌ها باید برای پردازش درخواست‌های API آماده و اجرا شوند. مؤلفه‌ها و ذخیره‌سازی‌های داده در پادهای «مرکزی» و «تحلیلی» برای پردازش APIها مورد نیاز نیستند، اما قابلیت‌های اضافی را به Edge اضافه می‌کنند.

تصویر زیر اجزای هر غلاف را نشان می دهد:

شما می توانید پیام پردازشگر و غلاف مسیریاب اضافی را به سه موردی که به طور پیش فرض ایجاد شده اند اضافه کنید. از طرف دیگر، می توانید اجزای Edge اضافی را به یک pod موجود اضافه کنید. برای مثال، می‌توانید روترها و پردازشگرهای پیام اضافی را به غلاف "دروازه" اضافه کنید تا بارهای ترافیکی افزایش یافته را مدیریت کنید.

توجه داشته باشید که پاد "دروازه" شامل اجزای Edge Router و Message Processor است. روترها فقط درخواست ها را به Message Processors در همان pod ارسال می کنند و نه به Message Processors در سایر pods.

می توانید از فراخوانی API زیر برای مشاهده جزئیات ثبت سرور در پایان نصب برای هر پاد استفاده کنید. این یک ابزار نظارتی مفید است.

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

که در آن ms_IP آدرس IP یا نام DNS سرور مدیریت است و podName یکی است:

  • دروازه
  • مرکزی
  • تجزیه و تحلیل

به عنوان مثال، برای غلاف "دروازه":

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

خروجی را به شکل زیر می بینید:

[ {
  "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"
} ]

ویژگی type نوع مؤلفه را فهرست می کند. توجه داشته باشید که ذخیره‌گاه‌های داده Cassandra ثبت‌شده در پاد را فهرست می‌کند. در حالی که گره های Cassandra در غلاف "دروازه" نصب شده اند، ذخیره داده های Cassandra را مشاهده خواهید کرد که با همه پادها ثبت شده اند.

درباره سازمان ها

یک سازمان محفظه ای برای همه اشیاء در یک حساب Apigee است، از جمله API ها، محصولات API، برنامه ها و توسعه دهندگان. یک سازمان با یک یا چند پاد مرتبط است، جایی که هر پاد باید یک یا چند پردازشگر پیام داشته باشد.

در نصب Edge Private Cloud در محل، هیچ سازمانی به طور پیش فرض وجود ندارد. هنگامی که یک سازمان ایجاد می کنید، دو بخش از اطلاعات را مشخص می کنید:

  1. کاربری که به عنوان مدیر سازمان عمل می کند. سپس آن کاربر می تواند کاربران دیگری را به سازمان اضافه کند و نقش هر کاربر را تعیین کند.
  2. غلاف "دروازه"، غلاف حاوی پردازشگرهای پیام.

یک سازمان می تواند شامل یک یا چند محیط باشد. رویه نصب پیش فرض Edge از شما می خواهد که دو محیط ایجاد کنید: "test" و "prod". با این حال، می‌توانید در صورت لزوم محیط‌های بیشتری ایجاد کنید، مانند «استیجینگ»، «آزمایش» و غیره.

سازمان زمینه را برای برخی از قابلیت های Apigee فراهم می کند. به عنوان مثال، داده های نقشه کلید-مقدار (KVM) در سطح سازمان، به معنای از همه محیط ها، در دسترس است. سایر قابلیت‌ها، مانند کش کردن، به یک محیط خاص اختصاص دارند. داده های تجزیه و تحلیل Apigee با ترکیبی از سازمان و محیط تقسیم می شود.

در زیر، اهداف اصلی یک سازمان، از جمله مواردی که در سطح جهانی در سازمان تعریف شده اند، و مواردی که به طور خاص برای یک محیط تعریف شده اند، نشان داده شده است:

درباره محیط زیست

یک محیط یک زمینه اجرای زمان اجرا برای پراکسی های API در یک سازمان است. شما باید یک پروکسی API را برای دسترسی به یک محیط به آن مستقر کنید. می توانید یک پراکسی API را در یک محیط واحد یا در چندین محیط مستقر کنید.

یک سازمان می تواند شامل چندین محیط باشد. برای مثال، ممکن است یک محیط «dev»، «test» و «prod» را در یک سازمان تعریف کنید.

هنگامی که یک محیط ایجاد می کنید، آن را با یک یا چند پردازشگر پیام مرتبط می کنید. شما می توانید یک محیط را به عنوان مجموعه ای از پردازشگرهای پیام نامگذاری شده در نظر بگیرید که پراکسی های API روی آن اجرا می شوند. هر محیطی را می توان با همان پردازشگرهای پیام یا با پردازنده های مختلف مرتبط کرد.

برای ایجاد یک محیط، دو بخش از اطلاعات را مشخص کنید:

  1. سازمان حاوی محیط
  2. پردازشگرهای پیام که درخواست های پراکسی API را به محیط رسیدگی می کنند. این پردازشگرهای پیام باید در یک غلاف مرتبط با سازمان مادر محیط باشند.
    به‌طور پیش‌فرض، زمانی که یک محیط ایجاد می‌کنید، Edge همه پردازشگرهای پیام موجود در پاد «دروازه» را با محیط مرتبط می‌کند. همچنین، می‌توانید زیرمجموعه‌ای از پردازشگرهای پیام موجود را مشخص کنید تا پردازشگرهای پیام مختلف، درخواست‌ها را به محیط‌های مختلف رسیدگی کنند.

یک پردازشگر پیام می تواند با چندین محیط مرتبط باشد. به عنوان مثال، نصب Edge شما شامل دو پردازشگر پیام است: A و B. سپس سه محیط در سازمان خود ایجاد می کنید: "dev"، "test" و "prod":

  • برای محیط "dev"، شما پردازشگر پیام A را مرتبط می‌کنید زیرا انتظار حجم زیادی از ترافیک را ندارید.
  • برای محیط "تست"، شما Message Processor B را مرتبط می کنید زیرا انتظار حجم زیادی از ترافیک را ندارید.
  • برای محیط "prod"، شما هر دو پردازشگر پیام A و B را برای مدیریت حجم تولید مرتبط می‌کنید.

پردازشگرهای پیام اختصاص داده شده به یک محیط، همگی می‌توانند از یک پاد باشند، یا می‌توانند از چندین پاد باشند، که چندین منطقه و مرکز داده را در بر می‌گیرند. به عنوان مثال، شما محیطی را در سازمان خود "جهانی" تعریف می کنید که شامل پردازشگرهای پیام از سه منطقه است، یعنی سه مرکز داده مختلف: ایالات متحده، ژاپن و آلمان.

استقرار یک پراکسی API در محیط "جهانی" باعث می شود که پراکسی API در پردازشگرهای پیام در هر سه مرکز داده اجرا شود. ترافیک API که به یک روتر در هر یک از آن مراکز داده می رسد، فقط به پردازشگرهای پیام در آن مرکز داده هدایت می شود زیرا روترها فقط ترافیک را به پردازشگرهای پیام در همان pod هدایت می کنند.

درباره هاست های مجازی

یک میزبان مجازی درگاهی را در مسیریاب Edge که در آن یک پراکسی API در معرض دید قرار می‌گیرد، و با فرمت URL که برنامه‌ها برای دسترسی به پراکسی API از آن استفاده می‌کنند، تعریف می‌کند. هر محیطی باید حداقل یک میزبان مجازی تعریف کند.

اطمینان حاصل کنید که شماره پورت مشخص شده توسط میزبان مجازی در گره روتر باز است. سپس می توانید با درخواست به یک پروکسی API دسترسی داشته باشید:

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

کجا:

  • http یا https : اگر میزبان مجازی برای پشتیبانی از TLS/SSL پیکربندی شده است، از HTTPS استفاده کنید. اگر هاست مجازی از TLS/SSL پشتیبانی نمی کند، از HTTP استفاده کنید.
  • <routerIP>: <port> آدرس IP و شماره پورت میزبان مجازی است.
  • هنگام ایجاد پراکسی API ، {proxy-base-path} و {resource-name} تعریف می‌شوند.

به طور معمول، شما API های خود را برای مشتریانی با آدرس IP و شماره پورت منتشر نمی کنید. در عوض، یک ورودی DNS برای روتر و پورت تعریف می کنید. به عنوان مثال:

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

همچنین باید یک نام مستعار میزبان برای میزبان مجازی ایجاد کنید که با نام دامنه ورودی DNS مطابقت داشته باشد. از مثال بالا، یک نام مستعار میزبان myAPI.myCo.com را مشخص می کنید. اگر ورودی DNS ندارید، نام مستعار میزبان را روی آدرس IP روتر و پورت میزبان مجازی، به عنوان <routerIP>:port تنظیم کنید.

برای اطلاعات بیشتر، http://apigee.com/docs/api-services/content/virtual-hosts را ببینید.

اولین سازمان، محیط و میزبان مجازی خود را ایجاد کنید

پس از تکمیل فرآیند نصب Edge، اولین اقدام شما معمولاً ایجاد یک سازمان، محیط و میزبان مجازی از طریق فرآیند "onboarding" است. برای انجام Onboarding، دستور زیر را در گره Edge Management Server اجرا کنید:

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

این دستور یک فایل پیکربندی را به عنوان ورودی می گیرد که کاربر، سازمان، محیط و میزبان مجازی را تعریف می کند.

به عنوان مثال، شما ایجاد می کنید:

  • کاربری که انتخاب کرده اید به عنوان مدیر سازمان فعالیت کند
  • سازمانی به نام نمونه
  • محیطی در سازمان به نام prod که با تمام پردازشگرهای پیام در غلاف "دروازه" مرتبط است.
  • یک میزبان مجازی در محیط به نام پیش فرض که اجازه دسترسی به HTTP را در پورت 9001 می دهد
  • نام مستعار میزبان برای میزبان مجازی

پس از اجرای آن اسکریپت، می توانید با استفاده از یک URL به شکل زیر به API های خود دسترسی داشته باشید:

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

بعداً می توانید هر تعداد سازمان، محیط و میزبان مجازی را اضافه کنید.

برای کسب اطلاعات بیشتر در مورد ورود به سازمان، به سازمانی که در داخل کشتی وجود دارد مراجعه کنید.