نام (NAME)

gdnsd-plugin-metafo - پلاگین gdnsd برای تغییر مسیر اضطراری چندسطحی (meta-failover) نشانی‌ها

خلاصه (SYNOPSIS)

نمونه‌ای از حداقل پرونده پیکربندی gdnsd با استفاده از این پلاگین:

plugins => {
  metafo => {
    resources => {
      prod_www => {
        datacenters => [ dc-01, dc-02, dc-03 ]
        dcmap => {
          dc-01 => 192.0.2.1
          dc-02 => { lb01 => 192.0.2.2, lb02 => 192.0.2.3 }
          dc-03 => [ 192.0.2.4, 192.0.2.5, 192.0.2.6 ]
        }
      },
      prod_foo => {
        datacenters => [ dc-01, dc-02, dc-bk ]
        dcmap => {
          dc-01 => { lb01 => 192.0.1.1, lb02 => 192.0.1.2 }
          dc-02 => [ 192.0.5.1, 192.0.5.2, 192.0.5.3 ]
          dc-bk => fallback.static.cname.example.org.
        }
      }
    }
  }
}

نمونه‌ای از رکوردهای منبع (RR) در zonefile در منطقه example.com:

www      600 DYNA metafo!prod_www
www-dc01 600 DYNA metafo!prod_www/dc-01
foo      700 DYNC metafo!prod_foo

توضیحات (DESCRIPTION)

gdnsd-plugin-metafo یک فراروش/متاپلاگین (meta-plugin) است. این پلاگین تغییر مسیر اضطراری (failover) نشانی‌ها را با ترتیبی ایستا بین چندین "datacenter" (مراکز داده که ممکن است با مراکز داده واقعی مطابقت داشته یا نداشته باشند، و صرفاً یک برچسب مناسب هستند) انجام می‌دهد. هر مرکز داده بر حسب سایر پلاگین‌ها مانند "multifo"، "weighted" و غیره، همان‌طور که در ادامه توضیح داده شده است، تعریف می‌شود.

پیکربندی - سطح بالا (CONFIGURATION - TOP-LEVEL)

سطح بالای پیکربندی پلاگین metafo (یعنی "plugins => { metafo => { ... } }") تنها از یک کلید ثابت و الزامی پشتیبانی می‌کند: "resources"، که مقدار آن باید یک هش (hash) باشد. محتوای "resources" شامل یک کلید به ازای هر منبع نام‌گذاری‌شده است که مقدار آن، آن منبع را تعریف می‌کند.

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

پیکربندی - منابع (CONFIGURATION - RESOURCES)

تمامی کلیدهای درون بخش resources نشان‌دهنده منابع نام‌گذاری‌شده هستند که می‌توانند توسط رکوردهای "DYNA" در zonefileها ارجاع داده شوند (مانند "www DYNA metafo!resource_name"). مقدار هر منبع باید یک هش کلید-مقدار باشد که خود آن منبع را پیکربندی می‌کند. نمونه ساختاری سبک:

plugins => {
  metafo => {
    resources => { resA => { ... }, resB => { ... } }
  }
}

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

"datacenters = [ A, B, C, ... ]"

آرایه‌ای از نام‌های مراکز داده، الزامی است. این مجموعه برچسب‌های نام مراکز داده مورد استفاده برای این منبع است، به ترتیبی که برای تغییر مسیر اضطراری (failover) بررسی خواهند شد.

"dcmap = { ... }"

هش، الزامی است. "dcmap" یک هش کلید-مقدار است که کلیدهای آن باید دقیقاً همان فهرست مراکز داده تعریف‌شده در فهرست "datacenters" این منبع باشند، و مقادیر آن، پیکربندی نشانی هر مرکز داده را مشخص می‌کنند. نمونه ساختاری حداقل دیگری تا این سطح:

plugins => {
  metafo => {
    resources => {
      resA => {
        datacenters => [ dc01, dc02 ],
        dcmap => {
          dc01 => ???
          dc02 => ???
        }
      }
    }
  }
}

مقادیر به ازای هر مرکز داده ("???" در بالا) می‌توانند چندین شکل به خود بگیرند که در بخش بعدی مستند شده‌اند.

"skip_first = true"

اگر این پرچم بولی پیکربندی تنظیم شود، کد حل‌کننده (resolver) هنگام تفکیک این منبع، از اولین مرکز داده صرف‌نظر می‌کند. این مورد بیشتر در زمینه پلاگین geoip کاربرد دارد و در آنجا با جزئیات بیشتر مورد بحث قرار گرفته است.

هر کلیدی غیر از "datacenters" و "dcmap" در سطح منبع، به عنوان پیش‌فرض‌های موروثی برای پیکربندی هر مرکز داده درون "dcmap" عمل می‌کند.

تفکیک به ازای هر مرکز داده (PER-DATACENTER RESOLUTION)

مقدار مراکز داده درون بخش "dcmap" یک منبع می‌تواند اشکال متعددی داشته باشد. درک این نکته حائز اهمیت است که در بیشتر موارد، plugin_metafo خود مستقیماً با نتایج این سطح سروکار ندارد، بلکه کار را در این محدوده به سایر پلاگین‌ها واگذار می‌کند. این زیرپلاگین‌ها نیز به نوبه خود، خرابی کامل در سطح خود را به metafo اطلاع می‌دهند، که این همان اطلاعاتی است که metafo برای تشخیص انتقال اضطراری به مرکز داده بعدی در فهرست از آن استفاده می‌کند.

مستقیم‌ترین و واضح‌ترین روش برای این کار، استفاده از یک ارجاع مستقیم به شکل "%plugin!resource" است، همان‌طور که در اینجا نشان داده شده است:

plugins => {
  metafo => {
    resources => {
      resA => {
        datacenters => [ dc1, dc2 ],
        dcmap => {
          dc1 => %multifo!res_mfo1
          dc2 => %multifo!res_mfo2
        }
      }
    }
  }
  multifo => {
    res_mfo1 => { lb01 => 192.0.2.1, lb02 => 192.0.2.3 }
    res_mfo2 => { lb01 => 192.0.2.111, lb02 => 192.0.2.113 }
  }
}

با این حال، برای ساده‌تر کردن کار در موارد ساده، plugin_metafo می‌تواند پیکربندی پلاگین سطح پایین‌تر را از روی یک هش ایجاد (سنتز) کند، مانند این:

plugins => {
  metafo => {
    resources => {
      resA => {
        datacenters => [ dc1, dc2 ],
        dcmap => {
          dc1 => { plugin => multifo, lb01 => 192.0.2.1, lb02 => 192.0.2.3 }
          dc2 => { lb01 => 192.0.2.111, lb02 => 192.0.2.113 }
          # موارد بالا عملاً به این صورت در نظر گرفته می‌شوند:
          # dc1 => %multifo!metafo_resA_dc1
          # dc2 => %multifo!metafo_resA_dc2
        }
      }
    }
  }
  # بخش‌های زیر در پرونده پیکربندی شما وجود ندارند، بلکه چیزی هستند که plugin_metafo
  #   برای پشتیبانی از موارد بالا تولید می‌کند:
  #multifo => {
  #  metafo_resA_dc1 => { lb01 => 192.0.2.1, lb02 => 192.0.2.3 }
  #  metafo_resA_dc2 => { lb01 => 192.0.2.111, lb02 => 192.0.2.113 }
  #}
}

درون هشی مانند بالا، کلید ویژه "plugin" در داخل حذف شده و برای نام‌گذاری پلاگینی که پیکربندی را برای آن ترکیب می‌کنیم استفاده می‌شود. در صورت عدم تعیین، "plugin" به طور پیش‌فرض "multifo" خواهد بود. توجه داشته باشید که "plugin" همچنین می‌تواند در سطح منبع (درست درون بخش "resA") تعیین شود تا مقدار پیش‌فرض را برای تمام مدخل‌های "dcmap" در یک منبع تغییر دهد، و همچنین می‌تواند در بیرونی‌ترین دامنه (درست درون بخش "metafo") مشخص شود تا مقدار پیش‌فرض را برای تمام منابع تغییر دهد.

مقدار پیش‌فرض ارث‌رسیده برای "plugin"، همچنین پیش‌فرض برای فرم ارجاع مستقیم "%plugin!resource" است که پیش‌تر به آن اشاره شد. با نام پلاگین پیش‌فرض مناسب، می‌توان آن را به صورت کوتاه‌شده "!resource" نوشت.

همین ساختار وراثت کلید-مقدار (سطح بالا -> سطح به ازای هر منبع -> سطح به ازای هر مرکز داده) می‌تواند برای هر پارامتر دیگری در پیکربندی‌های منبع سنتز‌شده که مختص پلاگین(های) مورد استفاده به ازای مرکز داده هستند نیز به کار رود. یک نمونه رایج، پارامتر "service_types" است که اکثر پلاگین‌های پشتیبانی‌کننده از نتایج نشانی پایش‌شده دارند. توجه داشته باشید که این مقادیر دیگر (مانند service_types) فقط برای منابع سنتز‌شده اعمال می‌شوند، نه برای ارجاع‌های مستقیم مانند "%multifo!foo"، که باید به طور کاملاً جداگانه در پیکربندی آن پلاگین پیکربندی شوند.

سه مقدار میان‌بر احتمالی دیگر برای مراکز داده وجود دارد: یک نشانی مستقیم منفرد، آرایه‌ای از نشانی‌ها، یا یک نام میزبان CNAME تکی. اگر یک نشانی IP تکی یا آرایه‌ای از نشانی‌های IP مشخص شود، plugin_metafo از آنها هشی سنتز می‌کند که در آن پلاگین به اجبار روی "multifo" تنظیم شده است (زیرا نمی‌تواند ساختار نحوی هش‌ها را برای سایر پلاگین‌ها که ممکن است متفاوت باشند بداند)، و به آنها برچسب‌های نشانی 1، 2 و غیره می‌دهد.

اگر مقدار برای یک مرکز داده یک نام میزبان CNAME تکی باشد، هیچ زیرپلاگینی استفاده نمی‌شود و آن نتیجه CNAME مستقیماً بازگردانده می‌شود. توجه داشته باشید که هر منبعی با چنین مدخلی فقط می‌تواند با رکوردهای "DYNC" استفاده شود و نه رکوردهای "DYNA" (همانند وضعیتی که پیکربندی هر زیرپلاگینی قادر به بازگرداندن داده‌های CNAME باشد).

یک نمونه بسیار کامل‌تر که بیشتر ویژگی‌های فوق را نشان می‌دهد:

plugins => {
  metafo => {
    plugin => multifo # تغییر پیش‌فرض برای تمام منابع
    service_types => [ bar ] # مقدار پیش‌فرض service_types برای موارد سنتز‌شده در زیر
    resources => {
      resA => {
        plugin => multifo # تغییر پیش‌فرض برای این منبع
        service_types => [foo, bar] # مقادیر service_types برای موارد سنتز‌شده در زیر:
        datacenters => [ dc1, dc2, dc3, dc4, dc5, dc6, dc7, dc8 ],
        dcmap => {
          dc1 => { plugin => multifo, lb01 => 192.0.2.1, lb02 => 192.0.2.3 }
          dc2 => { lb01 => 192.0.2.111, lb02 => 192.0.2.113 }
          dc3 => %simplefo!foo
          dc4 => { plugin => simplefo, primary => 192.0.2.100, secondary => 192.0.2.101 }
          dc5 => !bar
          dc6 => 192.0.2.150
          dc7 => [ 192.0.2.180, 192.0.2.181 ]
          dc8 => last.resort.example.com.
        }
      }
    }
  }
  # در زیر، بخش‌های کامنت‌شده پیکربندی سنتز‌شده توسط plugin_metafo را نشان می‌دهند،
  #   در حالی که بقیه ارجاعات مستقیم هستند که باید به صورت دستی در اینجا مشخص می‌شدند:
  multifo => {
    # metafo_resA_dc1 => { lb01 => 192.0.2.1, lb02 => 192.0.2.3, service_types => [foo, bar] }
    # metafo_resA_dc2 => { lb01 => 192.0.2.111, lb02 => 192.0.2.113, service_types => [foo, bar] }
    bar => { asd => 192.0.2.77, xyz => 192.0.2.88 }
    # metafo_resA_dc6 => { 1 => 192.0.2.150, service_types => [foo, bar] }
    # metafo_resA_dc7 => { 1 => 192.0.2.180, 2 => 192.0.2.181, service_types => [foo, bar] }
  }
  simplefo => {
    foo => { primary => 192.0.2.80, secondary => 192.0.2.81 }
    # metafo_resA_dc4 => { primary => 192.0.2.100, secondary => 192.0.2.101, service_types => [foo, bar] }
  }
}

توجه داشته باشید که در مثال بالا، "%multifo!bar" و "%simplefo!foo" به جای مقدار مشخص‌شده در سطح metafo، مقدار پیش‌فرض "service_types = up" خود را خواهند داشت، زیرا سنتز نشده بودند. در صورت استفاده از ارجاعات مستقیم، هماهنگ نگه داشتن تمام service_types بر عهده شما خواهد بود.

منابع ساختگی به ازای هر مرکز داده (SYNTHETIC PER-DATACENTER RESOURCES)

این پلاگین نام‌های منبع اضافی و سنتز‌شده به ازای هر مرکز داده را از روی پیکربندی شما ایجاد می‌کند. آنها به صورت "resname/dcname" نام‌گذاری می‌شوند. برای مثال، اگر یک منبع metafo به نام "prodwww" را با فهرست مراکز داده "[ pri, sec ]" تعریف کنید، نام‌های منبع "prodwww/pri" و "prodwww/sec" سنتز می‌شوند و می‌توانند در رکوردهای zonefile استفاده شوند، مانند:

www-backup 300 DYNA metafo!prodwww/sec

هنگام استفاده، این نام‌های منبع سنتزی به ازای مرکز داده باعث می‌شوند که یک جستجو از فرآیند عادی تغییر مسیر اضطراری (failover) صرف‌نظر کند و مستقیماً نتایج حاصل از آن مرکز داده خاص را بازگرداند.

همچنین ببینید (SEE ALSO)

gdnsd.config(5), gdnsd.zonefile(5), gdnsd(8)

راهنمای gdnsd.

حق نشر و مجوز (COPYRIGHT AND LICENSE)

این پرونده بخشی از gdnsd است.

نرم‌افزار gdnsd یک نرم‌افزار آزاد است: شما می‌توانید آن را تحت شرایط «پروانه عمومی همگانی گنو» (GNU General Public License) همان‌طور که توسط بنیاد نرم‌افزارهای آزاد منتشر شده است، چه نسخه ۳ پروانه و یا (به انتخاب خودتان) هر نسخه بعدی آن، بازتوزیع کرده و/یا تغییر دهید.

نرم‌افزار gdnsd به این امید توزیع شده است که مفید واقع شود، اما بدون هرگونه ضمانت؛ حتی بدون ضمانت ضمنی قابل فروش بودن یا مناسب بودن برای یک هدف خاص. برای جزئیات بیشتر به پروانه عمومی همگانی گنو مراجعه کنید.

شما باید یک نسخه از پروانه عمومی همگانی گنو را همراه با gdnsd دریافت کرده باشید. در غیر این صورت، به http://www.gnu.org/licenses/ نگاه کنید.