Uçtan Uca Yazılım Tanımlı Veri Merkezleri Standardı (RedFish) Bölüm-2

Resim Kaynak:Freepik

Uçtan Uca Yazılım Tanımlı Veri Merkezleri Standardı (RedFish)
Bölüm-2

Celal Ünalp

DMTF'nin Redfish Standardı

Açık bir endüstri standardı belirtimi ve şeması olan Redfish, bir RESTful arabirimi belirtir ve mevcut istemci uygulamaları ve tarayıcı tabanlı GUI tarafından kullanılabilen tanımlı JSON yüklerini kullanır. Redfish, API hizmetlerini tanımlayan ve geliştiriciler ile son kullanıcılar için zengin bir araç ekosistemi sunan açık bir özellik olan OpenAPI'yi de destekler.

Redfish'in 1. sürümü sunuculara odaklanarak LAN üzerinden IPMI için güvenli, çok düğümlü bir benzetim sağlar. Sonraki Redfish sürümleri, ağ arabirimleri (NIC, CNA ve FC HBA gibi), PCIe anahtarlama, yerel depolama, NVDIMM, çok işlevli adaptörler, birleştirilebilirlik ve telemetri yönetimi eklemektedir. Standart aynı zamanda güvenlik için sertifika yönetimi ve ayrıcalık eşlemenin yanı sıra olay oluşturma, aygıt yazılımı ve standartlaştırılmış PUSH tarzı yazılım güncellemelerini de sağlar.

Ek olarak, Redfish ana bilgisayar arabirim spesifikasyonu, bir işletim sisteminde çalışan uygulamaların ve araçların önyükleme öncesi (gömülü yazılımı) aşaması dahil Redfish yönetim hizmetiyle iletişim kurmasını sağlar.

Redfish standardını tanımlarken protokol, veri modelinden ayrıdır ve bağımsız olarak revize edilmelerine izin verir. Şema tabanlı veri modeli ölçeklenebilir ve genişletilebilir ve sektör geliştikçe insanlar tarafından okunabilen ek tanımlarla gelişmeye devam edecektir.

Redfish v1.0 Özellik Seti

"IPMI sınıfı" verilerini alınması

•   Temel sunucu kimliği ve varlık bilgisi
•   Sağlık durumu
•   Sıcaklık sensörleri ve fanlar
•   Güç kaynağı, güç tüketimi ve eşikler

Temel G/Ç altyapı verilerinin alınması

•   LOM cihazları için ana bilgisayar NIC MAC adres(ler)i
•   Basit sabit sürücü durumu/hata raporlaması

Keşif işlemleri

•   Hizmet uç noktası (ağ tabanlı keşif)
•   Sistem topolojisi (kabinet/şasi/sunucu/düğüm)

Güvenlik

•   Oturum tabanlı HTTPS'den yararlanır

Ortak İşlemler

•   Sunucu yeniden başlatma/güç döngüsü
•   Önyükleme sırasını/cihazını değiştirme
•   Güç eşiklerini ayarlama

Erişim ve Bildirim

•   SSH üzerinden seri konsol erişimi
•   Uyarı/olay bildirim yöntem(ler)i
•   Olay Günlüğü erişim yöntemleri

BMC altyapısı

•   BMC ağ ayarlarını görüntüleme/yapılandırma
•   Yerel BMC kullanıcı hesaplarını yönetme

DMTF, Redfish ekosistemine açık kaynak katkılarının yanı sıra standart hakkında endüstri genelinden ortak inceleme ve geri bildirimleri mümkün kılan müşterek geliştirmeye açık yaklaşım sergilemektedir. Halka açık GitHub deposunda test, doğrulama ve diğer alanlar için çok sayıda açık kaynak aracı yayınlanmaktadır:

REST, HTTP, JSON ve OData

Tüm BT alanlarında, çeşitli ve benzer nedenlerle RESTful/JSON stili arabirimleri benimsenmekte ve hızla gelişmektedir.

Dil desteğini REST, HTTP ve JSON'un yaygınlığıyla birleştiren Redfish, BT yönetimi görevlerinin diğer BT ve devops görevleriyle aynı beceri seti ve araç zinciri kullanılarak gerçekleştirilmesine olanak tanır.

Bulut ekosistemi REST'i benimserken ve web API topluluğu da aynı şeyi yaptıkça, RESTful protokolleri hızla SOAP'ın yerini almıştır. RESTful protokollerini öğrenmek, SOAP'tan çok daha hızlıdır ve doğrudan HTTP işlemleriyle eşlenen bir veri modeli (REST kesin olarak bir protokol olmadığı için) olma basitliğine sahiptir.

Yaygın olarak kullanılan güvenlik modeli ve ağ yapılandırmasıyla HTTP, sistem yöneticiler ve uygulayıcılar tarafından iyi anlaşılmıştır.

JSON hızla modern veri formatı haline gelmiştir. Doğası gereği insan tarafından okunabilir, XML'den daha özlüdür, çok sayıda modern dil desteğine sahiptir ve web hizmeti API'leri için en hızlı büyüyen veri biçimidir.

JSON, katıştırılmış yönetilebilirlik ortamları için ek bir avantaja sahiptir: Çoğu Anakart Yönetim Denetleyicisi (BMC) zaten bir web sunucusunu desteklemektedir ve bir sunucuyu bir tarayıcı aracılığıyla yönetmek yaygındır. Redfish'te JSON kullanılarak, bir Redfish hizmetinden alınan veriler doğrudan tarayıcıda görüntülenerek verilerin ve programatik arayüzün anlam ve değer açısından tek tip olması sağlanır.

REST, HTTP ve JSON'a ek olarak Redfish, bir JSON yükündeki ortak özelliklerin yapısının yanı sıra şemayı, URL kurallarını ve adlandırmayı açıklamak için ortak OData v4 kurallarını benimser. Bu, Redfish hizmetlerinin büyüyen bir genel istemci kitaplıkları, uygulamaları ve araçları ekosistemi tarafından tüketilmesini de sağlar.

Bir JSON yükündeki şemayı, url kurallarını ve ortak özelliklerin adını ve yapısını açıklamak için yaygın OData kurallarının izlenmesi, yalnızca RESTful API'leri için en iyi uygulamaları ve araçları kapsamaz, ayrıca Redfish hizmetlerinin büyüyen bir jenerik OData istemci kitaplıkları, uygulamaları ekosistemi tarafından tüketilmesini sağlar.
Böylece Redfish ile her iki dünyanın da en iyisine, JSON geliştiricileri tarafından erişilebilen doğrudan bir API'ye ve artan sayıda OData istemcisine sahip olunur.

OData Şeması

OData, ISO standardizasyonu yolunda olan onaylanmış bir standarttır. OData, şeyleri varlıklar (nesneler) ve ilişkiler açısından, gerçek dünyadaki şeyler hakkında düşünme şeklimizi tanımlayan zengin bir şema tanımlama dili tanımlar.

OData'nın şema dili, ek açıklamalar yoluyla doğası gereği genişletilebilir. Bu uzantılar, URI'ler aracılığıyla benzersiz bir şekilde tanımlanarak paylaşılabilir ve "sözcük dağarcığı" olarak ortak semantik ile hizmetler ve sektörler arasında paylaşılabilir.

OData şeması, araçlar ve insan tarafından okunabilirlik nedeniyle çok hızlı geliştirilebilir.

JSON Şeması

JSON şeması IETF tarafından benimsendiğinden ve zaten JSON'da olduğundan (böylece protokol tarafından aktarılabilir) ilk aday standarttır.

Ayrıca genişletilebilir olduğundan, temel şemada temsil edilmeyen tüm niteleyiciler eklenebilir.

Ayrıca JSON olduğu için mevcut araç zinciri tarafından kullanılabilir. Ayrıca araçlar ve insan tarafından okunabilirlik nedeniyle şemayı çok hızlı geliştirmeye yardımcı olur.

Hypermedia API

Müşteriler bağımsız sunuculardan hiper ölçeğe ve ayrıca bölümlenebilir ve hatta sanal sistemlere kadar uzanan tek bir arabirime ihtiyaç duymaktadır.

Açık bir endüstri standardı belirtimi ve şeması söz konusu olduğunda sektör, birden fazla arayüzü veya programlama stilini destekleyemez, sayısız BT platformuyla eşleşecek tek bir API stili gereklidir.

Sabit bir URI API metodolojisi, çeşitli sunucu donanım biçimleri, bunların içindeki sunucular ve bunlarla ilişkili yöneticiler arasındaki çeşitli kapsama ilişkilerini göstermek için yeterli olmayacaktır.

Bu, birden-çoğa veya çoktan-çoğa kardinaliteye ihtiyaç duyulduğu anlamına gelir.

Ek olarak, API basit sistemler için kolay ve hiper ölçek için esnek olmalıdır.

Benzer kaynaklar için ilişkilendirmeleri ve koleksiyonları temsil etmek üzere HREF kullanım başarımı, hiper ortam API'lerinde kanıtlanmıştır.

Basit Kullanım Örneği

Aşağıdaki blok, Redfish kullanan bir sunucudan seri numarasını almak için kullanılan örnek Python kodunu göstermektedir:

Bu örnekteki çıktı şöyle görünecektir: 1A87CA442K

Temel Konsept
Redfish'te her URL bir kaynağı, hizmeti veya bir kaynak koleksiyonunu temsil eder. RESTful açısından, bu Tekdüzen Kaynak Tanımlayıcıları (URI'ler) doğrudan kaynaklara işaret eder ve istemciler kaynaklarla etkileşime girer.

Kaynak formatı, gerekirse müşterinin doğru semantiği belirlemek için kullanabileceği Redfish Şeması tarafından tanımlanır (Redfish semantiği büyük ölçüde sezgisel olacak şekilde tasarlanmıştır).

Redfish şeması üç biçimde tanımlanır.

OData Ortak Şema Tanımlama Dili'nde CSDL olarak tanımlanmıştır, böylece genel OData araçları ve uygulamaları onu yorumlayabilir.

Şema ayrıca Python betikleri, JavaScript kodu ve görselleştirme gibi diğer ortamlar için JSON şeması biçiminde tanımlanır.

Ayrıca şema, OpenAPI tarafından belirtildiği gibi YAML desteği de sağlar.

Redfish'te tüm kaynaklar, her zaman şu URL'de bulunan bir Hizmet Giriş noktasından (kök) bağlanır:

/redfish/v1

Ana kaynak türleri, bağımsız, çok düğümlü veya birleştirilmiş kabinet düzeyinde sistemlere izin vermek için "koleksiyonlarda" yapılandırılmıştır. Ek ilgili kaynaklar, bu koleksiyonlardaki üyelerden dallanır ve yayılır.

Redfish'te bir koleksiyon, benzer kaynaklardan oluşan bir grubu temsil eder. Örnek sistemler, yöneticiler ve şasi olarak verilebilir.

Hizmet kökü olarak "/redfish/v1/" kullanım zorunluluğu

Protokollerin taşıdıkları veri modelinden farklı bir yaşam döngüsü olacağından, bir sürüm oluşturma mekanizması gereklidir. Bu yapılandırma protokolün sürümünü temsil etmesi için seçilmiştir. Ayrıca kaynakların kendilerinin ayrı bir sürümü vardır (Type özelliğinin kullanımı)
.
RESTful dünyası, sabit URI metodolojisini benimsemiştir ve standart olmayan başlıklardan (X-anything gibi) uzaklaşmaktadır. Ek olarak, bazı araç setlerinde genel olarak başlıkları ve özel olarak X başlıklarını kullanmak zordur.

Redfish Kaynak Haritasında Öne Çıkanlar

Sistem, bir bilgisayar sisteminin mantıksal görünümünü temsil eder. Ana bilgisayar CPU'sundan erişilebilen herhangi bir alt sistem, bir sistem kaynağında temsil edilir. Her Sistem örneğinin CPU'ları, belleği ve diğer bileşenleri olacaktır. Bilgisayar sistemleri, Systems koleksiyonunun üyeleri olarak bulunur.

Şasi koleksiyonu, altyapının fiziksel özelliklerini temsil eden kaynakları içerir. Tek bir şasi kaynağı, sensörleri, fanları ve benzerlerini barındırabilir. Kabinetler, kasalar ve blade sunucular, şasi koleksiyonunda yer alan fiziksel kaynaklara örnektir. Redfish ayrıca, başka bir şasi içinde yer alan bir şasiyi temsil etmek için bir yöntem de sağlar.

Yöneticiler koleksiyonu, BMC'leri veya altyapıyı yöneten diğer bileşenleri içerir. Yöneticiler, çeşitli yönetim hizmetlerini yönetir ve ayrıca kendi bileşenlerine (NIC'ler gibi) sahip olabilir.

BAŞLANGIÇ ve KÖK

Redfish API'sini anlamanın kolay bir yolu, kullanımda olan bir uygulamayı görmektir, bu nedenle bu sonraki bölümlerde bir uygulama incelenecek ve bir uygulama aracılığıyla çeşitli mimari yapılar ve kavramlar açıklanacaktır.

Redfish bir hiper ortam API'sidir. Bu, tüm kaynaklara, kaynaklardan döndürülen URL'ler aracılığıyla ulaştığınız anlamına gelir. Ancak, her uygulamanın ortak bir başlangıç noktası olması için iyi bilinen tek bir URL vardır.
Bu URI, Redfish arabiriminin 1. sürümü için "/redfish/v1" şeklindedir.

Şema, müşteri tarafından kullanılabilecek veri türlerini, numaralandırma listelerini, özelliklerin bilgilendirici açıklamalarını, özellik davranışı hakkında normatif bilgileri ve diğer çok sayıda bilgi içerir. İstemcilerin, özellikle programatik istemcilerin, özellikler etrafındaki anlambilimi belirlemek için şemayı incelemeleri önerilir.

Redfish köküne erişmek için tarayıcınıza "HTTP://BMC_IP_ADRESİ/redfish/v1/" yazarak bir GET yapmanız yeterlidir.

Kaynak Konsepti

Her URL bir kaynağı temsil eder. Bu bir hizmet, koleksiyon, varlık veya başka bir yapı olabilir.

Ancak RESTful terimlerle, bu URI'ler kaynaklara işaret eder ve istemciler kaynaklarla etkileşime girer. Dolayısıyla, kaynak terimini gördüğünüzde, bunu bir URI'ye eriştiğinizde geri aldığınız şey olarak düşünebilirsiniz.

Kaynak formatı bir şema tarafından tanımlanır. Her kaynağın, müşterinin kaynakla ilgili semantiği belirlemek için kullanabileceği Redfish şemasında belirtilen belirli bir biçimi vardır (her şeyi mümkün olduğu kadar sezgisel hale getirilmiştir).

Redfish şeması gereği kaynaklar iki formatta tanımlanır:

Genel OData araçlarının ve uygulamalarının yorumlayabilmesi için OData şema biçiminde CSDL olarak tanımlanır.
Python betikleri, JavaScript kodu ve görselleştirme gibi diğer ortamlar için JSON şema biçiminde tanımlanır.

Bu sayede kaynağın yapısal özelliklerinin JavaScript değişkenleri olarak kullanılması, web sayfalarının ve etkin uygulamaların verilere doğrudan erişimine izin vermeleri amaçlanmıştır.

URI'ler yeniden başlatmalar boyunca kalıcıdır, ancak istemcilerin /redfish/v1/ ile başlaması ve kaynak URI'leri buradan keşfetmesi beklenir.

Yaygın bir hata, URI'ye odaklanmaktır. Redfish bir hiper ortam API'sidir, bu nedenle URI'ler, aynı üreticide bile uygulamalar arasında farklı olabilir. Mevcut durum nesneleri, istenen durum nesnelerinden ayrı olabilir.

İşlem Konsepti

Redfish API'sinde desteklenen işlemler GET, PUT, PATCH, POST, DELETE ve HEAD'dir. GET, gelişmiş bir REST eklentisi kullanmıyorsanız tarayıcınızın yapacağı tek şeydir. Yalnızca öykünücü ve gerçek uygulamalar diğer işlemleri destekleyecektir.

GET verileri alır. POST, kaynak oluşturmak veya eylemleri kullanmak için kullanılır.

DELETE bir kaynağı siler, ancak genelde silinebilecek yalnızca birkaç kaynak vardır.

HEAD, döndürülen gövde verileri olmadan bir GET gibidir ve bir Redfish uygulamasına erişen programlar tarafından URI yapısını bulmak için kullanılabilir.

PATCH, bir kaynaktaki bir veya daha fazla özelliği değiştirmek için kullanılırken PUT, bir kaynağı tamamen değiştirmek için kullanılır ancak genelde yalnızca birkaç kaynak tamamen değiştirilebilir.

PUT, değiştirme semantiğine sahip olduğundan bir PUT ile belirtilmeyen özellikler varsayılan değerlere (genellikle boş) sıfırlanabilir.

Örneğin, bir kaynak bir ayar verisine izin veriyorsa, PUT mevcut özellikleri temizlemek için kolay bir yol sağlar.

Yalnızca tek bir özelliği değiştirmek istediğinizde veya bilmediğiniz özellikler varsa, tüm özellikleri göndermeniz gerekmez. Bu durumlarda PATCH her zaman kısmi bir değiştirme yapar.

İstenmeyen özelliklerin üzerine yazmadığından ve daha güvenli kabul edildiğinden, güncellemeler için tercih edilen yöntem PATCH'dir.

Sürüm Konsepti

Veri modelinin, kendisine eklenen uzantılar da dahil olmak üzere zaman içinde değişmesi beklenmektedir. Bu nedenle, protokolden ayrılması gerekmiştir. Bununla birlikte, spesifikasyonun protokol kısmı nispeten sabit kalmaktadır. Dolayısıyla, tüm belirtimi değiştirmek yerine, etkilenmeyen belirtim bölümlerinin gereksiz sürümlerini izole etmeye çalışılmaktadır.

Diğer veri modellerine benzer şekilde kesin ileri uyumluluk kuralları belirtim yol haritasında yer almaktadır.

Tek sabit, tür ek açıklamasının kaynak tanımına benzersiz, başvurulabilir URI içermesidir, böylece kaynak türünden bağımsız olarak şema her zaman elde edilebilmektedir.

Redfish'in iki tür sürümü vardır, protokol sürümü ve kaynak şeması sürümü.

Protokolün sürümü URI'dedir, bu yüzden /redfish/v1/ başlangıç noktasıdır. Bu, protokolün birinci versiyonuna eriştiğiniz anlamına gelir. Sürüm 1, şu anda mevcut olan tek sürümdür. Bu başlangıç URI'si, uygulamanın Sürüm 1 Redfish Spesifikasyonu ile uyumlu olduğunu gösterir.

OData v4 temel alındığından, uygulamaların ayrıca OData protokol başlığının (OData-Version) 4 değerine sahip olmasını gerekmektedir.

Her kaynağın bir kaynak türü tanımı vardır. Kaynak türleri, sürümlü ad alanlarında tanımlanır.

Her kaynak örneği, "@odata.type" OData türü ek açıklaması kullanılarak temsil edilen türe sahiptir.

Tür ek açıklamasının değeri, sürümlü ad alanı da dahil olmak üzere kaynak türünün URI'sidir.

Dolayısıyla, "@odata.type" : "#ServiceRoot.v1_0_0.ServiceRoot" ifadesini gördüğünüzde, ServiceRoot şemasının 1.0.0 sürümünde tanımlanan ServiceRoot türü tanımına uyan bir kaynakla uğraşıyorsunuz demektir.

Karşılık gelen şema dosyası, Redfish şema deposunda /schema/v1/ServiceRoot konumunda bulunur.

Dolayısıyla, tür için tam URI "/schema/v1/ServiceRoot#ServiceRoot.V1_0_0.ServiceRoot" şeklinde olacaktır.

Şema dosyası, kaynak türü tanımında kullanılan diğer türleri (örneğin, yapılandırılmış türler ve sıralamalar) içerebilir, bunlar aynı kaynak yoluna sahip olabilir, ancak parça, tipik olarak aynı ad alanı içinde farklı bir tür tanımlayabilir.

Referanslar

Bağlantılar bölümüne eriştiğinizde, içinde diğer kaynaklara referanslar olacaktır.

JSON'un başka bir kaynağa başvurmak için yerel referans türü yoktur. Redfish, istemcinin şemaya başvurmasını gerektirmeden (basit işlemler için) tamamen bağlı bir kaynak ağacı barındırır.

Bu nedenle, bu belirtim, başka bir dahili veya harici kaynağa bir referansı temsil etmek için OData kurallarını kullanır.

OData kurallarını izleyen diğer kaynaklara referansları temsil eden özellikler, "@odata.id" ekli bir özellik adıyla tanımlanır.

Diğer başvuru türlerinin URL'lerini temsil eden özellikler, örneğin harici bir yardım konusu, bir URL'yi temsil ettiklerini belirten bir ek açıklama ile meta verilerde dize özellikleri olarak tanımlanır.

URI'ler mutlak veya görecelidir. Mutlak olanlar IP adresine sahip olmayacak, ancak /redfish/v1/ ile başlayacaktır.

Ana Nesneler

"Ana" nesneler Sistemler, Yöneticiler ve Şasi'dir (Systems, Managers, Chassis). Bunların hepsi aslında birer koleksiyondur.

Sistemler tipik sunucunuzu temsil eder. CPU'dan veri yoluyla erişilen her şey bir sistem olarak temsil edilir ve bunların tümü sistem koleksiyonundadır.

Yöneticiler, BMC veya altyapıyı yöneten diğer bileşenleri temsil eder. Yöneticiler, çeşitli yönetim hizmetlerini yönetir ancak aynı zamanda kendi cihazlarına (NIC'ler gibi) sahiptir.

Şasi, altyapının fiziksel yönlerini ve kapsamını temsil eder. Kabinetler, muhafazalar, içlerindeki blade sunucular, bunların hepsi ve daha fazlası Şasidir. Şasiler sensörleri, fanları ve benzerlerini barındırır.

Ayrıca bir Şasi içinde bir başka Şasiyi temsil etmenin bir yolu da tanımlanmıştır.

Sistemlerin bir veya daha fazla yöneticisi olabilir (çünkü bazı yöneticiler yedekli yapıdadır) ve tek bir Şasi içinde bulunabilir. Yöneticiler daima bir şasi içindedir ve birden fazla sistemi yönetebilir ve Şasi birden fazla Sistem ve/veya Yönetici barındırabilir.

Koleksiyon yanıtları, "Members@odata.count" adında bir sayaç özelliğine ve üyelerin listesini veya üyelere bağlantılar içeren bir "Members" nesnesine sahiptir.

Üyelere olan bağlantılar, üyenin URL'sini içeren tek bir "@odata.id" özelliğine sahip JSON nesneleri olarak temsil edilir.

Koleksiyonlar sayfalandırılabilir: "@odata.nextLink" adlı özelliğe sahip koleksiyonlar URLvalue özelliğini kullanabilir..

ServiceRoot nesnesine baktığınızda ayrıca Oturumlar gibi hizmetler olduğunu da görebilirsiniz.

Ortak Özellikler ve Ek Açıklamalar

Modeli incelerken, aynı özelliklerden bazılarının tekrar ettiği ve ortak özelliklere her biri tarafından başvurular yapıldığı görülmektedir.

Her kaynakta "Name"(Ad) ve "Id"(Kimlik) zorunlu olarak bulunmaktadır.

"Status”(Durum), tüm kullanımlarda aynı tanıma sahip katıştırılmış bir nesne olarak bulunmaktadır.

Ortak özelliklere, her kaynağın şeması tarafından şema içindeki bir odata "Reference"(Referans) öğesi aracılığıyla başvurulur, böylece aynı tanım her yerde kullanılır.

Müşterilere hangi eylemlerin çağrılabileceğini bildiren "Actions”(Eylemler) ve kaynağın standart tanımında üreticiye özel uzantıları olan "OEM" de ortak bölümlerde bulunur.

Ek açıklamalar olan özellikler de vardır. "@" ile başlayan özellikler, nesnenin tamamı için ek açıklamalardır, özellik adının ortasında "@" bulunan özellikler ise tek bir özelliğe açıklama eklemek için kullanılır.

Bu özelliklere örnek olarak, bir kaynağı tanımlayan şemayı bulmak için kullanılan "@odata.type" verilebilir.

Bir kaynağın URL'sine sahip olan "@odata.id" özelliğidir.

"Members"(Üyeler) dizisindeki girişlerin sayısını tanımlayan Members@odata.count özelliğidir.

Kaynak için ayarları belirtmek için kullanılan "@Redfish.Settings" (bununla ilgili daha sonra konuşacağız).

Diğer bir yaygın ek açıklama "@odata.context" şeklindedir.

Teknik olarak, meta veri belgesinin yalnızca doğrudan kullandığı türlerden herhangi birini tanımlaması veya bunlara başvurması gerekir ve farklı yükler, farklı meta veri belgelerine başvurabilir.

Örneğin, /redfish/v1/Systems/1 kaynağında, "/redfish/v1/$metadata#ComputerSystem.ComputerSystem" değeriyle "@odata.context" özelliği incelenebilir.

Ayrıca "@Redfish.Copyright" adlı bir ek açıklama da telif hakkı beyanı olarak bulunmaktadır.

Eylemler

Ayarına bağlı olarak sistemi sıfırlayan veya kapatan "düğme" gibi şeyler Sistemde kolayca temsil edilemediğinden REST kullanılarak her şey kolayca yapılamaz.

Bu sebeple "Actions"(Eylemler) müşteri için atomik bir eylem olarak daha kolay ifade edilen uzun ömürlü işlemler için tasarlanmıştır.

Eylemler, kaynağa POST ile yapılır.

Herhangi bir kaynakta hangi eylemlerin desteklendiğini "Actions"(Eylemler) özelliğine bakarak anlayabilirsiniz.

Diğer Konseptler

Oturumlar

Normalde, bir oturum oluşturulmadan yalnızca /redfish/v1/ köküne erişilebilir.

Güvenli modda çalışan bir öykünücünüz varsa veya gerçek bir uygulamayla çalışıyorsanız, bir oturum oluşturmanız gerekir.

Öncelikle, uygulamanız için geçerli bir BMC kullanıcı adı ve parolasına sahip olmanız beklenir.

Bir oturum oluşturabilmeniz için, kullanılan URI'nin güvenli olmayan POST için kullanılmasına da izin verilir.

Bu URI çoğu durumda /redfish/v1/Sessions şeklindedir ve bağlantılar altındaki Sessions özelliğine bakılarak ve /redfish/v1/ hizmet kökünde @odata.id özelliğinin değeri bulunarak belirlenebilir.

Aşağıdaki POST gövdesini içeren /redfish/v1#/Links/Sessions/@odata.id tarafından belirtilen URI'ye bir HTTP POST tarafından bir oturum oluşturulur:

Dönüş JSON gövdesi, bir oturum belirtecine ve konum başlığına sahip bir X-Auth-Token başlığını ve yeni oluşturulan oturum nesnesinin bir temsilini içerir.

Hizmetinize yapılan sonraki tüm istekler için aynı başlıktaki yanıt X-Auth-Token belirteç dizesini kullanacaksınız.
Oturumu silme zamanı geldiğinde, yanıtta (örnek /redfish/v1/Sessions/Administrator1) @odata.id'de döndürülen URL'de DELETE işlemi yapabilirsiniz.

Yedeklilik

Şasi görünümünde "Termal" bağlantısını izleyerek fanlara bakıldığında Redfish'in yedekli yapılanmaları nasıl gösterdiği anlaşılabilmektedir.

"Redundancy"(Yedeklilik) adlı bir dizi, ilişkili öğe özelliklerinde aynı değerleri kullanan kümedeki iki veya daha fazla fanı gösterir.

Yedeklilik, Redfish'te ortak bir şema tanımına sahiptir ve içinde, yedeklilikle ile ilgili diğer önemli nitelikleri göstermek için üyelerin yanı sıra başka özellikler de vardır.

@odata.id değerleri yedeklilik kümesi üyelerine yönelik işaretçiler olduğundan, müşteri bu şekilde hangi öğelerin hangi yedeklilik kümesine ait olduğunu anlayabilir.

Bununla birlikte, "@odata.id" özelliğinin değeri tüm bir kaynak olmak zorunda değildir. Bu özelliğin değeri iki biçimde olacaktır: bir JSON İşaretçisi veya bir OData başvurusu.

Bir JSON İşaretçisi söz konusu olduğunda, içinde kaynağın nerede durduğunu ve özellik modelinin nerede başladığını gösteren bir # olacaktır.

Şemanın ayrıca özelliğe bir referansı olacaktır. JSON İşaretçisi değerine örnek olarak "/redfish/v1/Chassis/1/Thermal#/Fans/0" verilebilir.

Bir OData başvurusu olması durumunda, içinde # olmayacaktır. Şema, özelliğin bir tanımına sahip olacaktır. JSON Pointer değerine örnek olarak /redfish/v1/Chassis/1/Thermal/Fans/0" verilebilir..

RelatedItem (İlişkili Öğe)

Sensörler gibi nesneleri izledikleri şeylerle birleştirmenin bir yoluna ihtiyacımız olacağından, yedekleme gibi üye kümelerini göstermenin bir yoluna da ihtiyacımız vardı.

URL'ler tercih edilen başvuru mekanizmasıdır, ancak kaynağın tamamına değil, bir kaynak içindeki tek tek özelliklere başvurmamız gerekeceğinden, biçimi bir JSON İşaretçisi veya bir OData biçimi olması mümkün olan bir "RelatedItem"(İlişkili Öğe) tanımlaması yaratılmıştır.

Yine "Termal" kaynağında, Sıcaklık dizisi öğelerinin içinde "@odata.id" bulunan bir RelatedItem özelliğine sahip olduğunu görebilirsiniz.

Bu, sıcaklık sensörünün ölçtüğü alt kaynağa, bir işlemciye veya emiş fanlarına bir referanstır.

Yedeklilik bağlantıları gibi, değer bir alt kaynağa bağlı olabilir. Böylece müşteri, bu sıcaklık sensörü tarafından neyin ölçüldüğünü belirleyebilir.

İlişkili Öğe, ortak bir şema tanımına sahip olmakla birlikte, kullanımında duruma bağlıdır. Ancak her zaman iki farklı kaynak veya alt kaynak arasındaki ilişkiyi göstermek için kullanılır.

Yedeklilik gibi, "@odata.id" özelliğinin değerinin tüm bir kaynağa eşit olması gerekmez.

Hizmetler (Services)

Servis kökü, Görevler, Oturumlar, EventService ve AccountService gibi bazı ortak hizmetleri de içermektedir.

Görevler, genellikle Eylemler sonucunda başlatılmış olabilecek işlerin bir listesini içerir.

Oturumlar daha önce açıklandığı şekilde açık oturumların bir listesini içerir.

Hesap Hizmeti, yeni kullanıcıların oluşturulmasına yardımcı olur.

Kayıtlar (Registries)
İleti kayıtları, yönetim işlemcisinin olaylarda ve hatalarda kullanılmak üzere kısa bir tanımlayıcıyı tutmasına izin verir. Böylece, istemciler daha sonra asıl iletiyi belirlemek için bir kayıt defterinde arayabilirler.

Ayrıca bu bölümde mesaj bazında parametre değişimi için mekanizmalar mevcuttur.

Yönetim işlemcisinin çevirileri içermesi gerekmediğinden, mesaj kayıt defterlerinin ayrı varlıklar olarak bulunmasıyla yerelleştirmeyi desteklemek kolaydır.

Böylece, kayıt defterinin kendisi tercüme edilir ve müşteri daha sonra gereken içeriği görüntüleyebilir.

Başlıklar (Headers)

Ortak HTTP başlıklarının bir alt kümesi, her Redfish hizmeti tarafından desteklenir.

Bunların tam listesi spesifikasyonda yer almaktadır, ancak en alakalı olan ikisi, Accept Header ('application/json' olarak ayarlanmalıdır) ve X-Auth-Token'dır.

Ancak gerçek bir uygulamadan alacağınız ve statik bir modelden göremeyeceğiniz çok daha fazlası bulunmaktadır.

Varlık Etiketleri (ETags)

ETag'ler, tarayıcılar tarafından işleri önbelleğe alarak optimize etmek için kullanılır. Bir If-Match yaparlar ve eşleşirse, verileri yeniden aktarma zahmetine girmezler. If-Match başlığının kullanılmasıyla sunucuya basit bir zaman damgasından daha sağlam bir referans sağlama seçeneği sunulmaktadır.

RedFish bunları bir nesnenin değişip değişmediğini belirlemek için kullanır. Bu nedenle, bir PUT yapılırsa veya bir araç (konsoldaki BIOS yapılandırması gibi) işlemi gerçekleşirse her ETag değişecektir.

ETag'in değeri yalnızca sunucunun sağlayabileceği kadar iyi olacağından, pratikte bunun önemi yoktur. Spesifikasyonda belirtilen farklı ETag modelleri (Zayıf/Güçlü) göz önüne alındığında, RFC2616'nın izin verdiği model ve algoritma kararı sunucu uygulamasına bırakılmıştır.

ETag değişiklik verileri, kaynaklar hakkında özel bilgileri sızdırabileceğinden, üreticiye bırakılan mevcut birçok ETag uygulaması bu meta verileri gösterir ve riski kabul eder.

Kaynakları Güncelleme

Basit GET, PUT/PATCH yöntemi, istemcinin mevcut yapılandırmayı alabileceği ve aynı kaynak URI'sine istenen yeni bir yapılandırmayı PUT veya PATCH yapabileceği bir modeldir.

Bir PUT veya PATCH'in başarısı, HTTP durum kodu ve yanıt gövdesi tarafından belirlenir.

Bu, ürün yazılımının eylemleri ve yapılandırma değişikliklerini uygun şekilde işleyebildiği ve yanıtlayabildiği Redfish hizmetlerinin kendi verileri gibi içsel sağlayıcılarla etkileşime yöneliktir.

PUT veya PATCH üzerine, HTTP yanıtı bir HTTP durum kodu ve hata durumunda yanıt gövdesi olarak bir Genişletilmiş Hata Bilgisi yapısı içerir.

Hizmet için belirleyici davranış, hem PUT hem de PATCH kullanımıyla istemci veya sunucu için karmaşık mantık olmadan elde edilir. PUT her zaman tam bir değiştirme yapar. PATCH her zaman kısmi bir değiştirme yapar.

PATCH, endüstride geniş çapta benimsenmiş, halihazırda Open Stack ve diğer birçok API tarafından desteklenmektedir ve pek çok web sunucusunda mevcuttur.

Geçerli Yapılandırmalar ve Ayarlar

Redfish'te temel olarak iki tür nesne vardır: Geçerli Yapılandırmalar ve Ayarlar.

Çoğu nesne, herhangi bir kaynağın mevcut durumunu temsil eder. Nadiren, bir kaynakta "@Redfish.Settings" adlı bir özellik görürsünüz.

Bu ek açıklama, yapılandırma için PUT ve PATCH nerede yapacağınızı söyleyen bir bağlantıya sahiptir ve kaynağın gelecekteki durumunu temsil eder.

Bazı kaynaklar, üzerlerindeki değişiklikleri hemen işleyebilir, diğerleri ise sistemin veya hizmetin yeniden başlatılmasını gerektirebilir.

"@Redfish.Settings", müşteriye bunun ne tür bir kaynak olduğunu ve değişiklikleri nerede yapacağını bildirmek için kullanılır.

"@Redfish.Settings" özelliğini görürseniz, sıfırlama veya yeniden başlatma gibi bir sonraki fırsatta alınacak değişiklikleri yapmak için bir kaynağa bağlantı vardır. Bir ayarlar bağlantısı görmüyorsanız, nesneye yapılan herhangi bir PATCH hemen gerçekleştirilmelidir.

Ayarların kaynağa en son ne zaman uygulandığı, zaman, bir ETag ve ayarların "canlı" uygulanabilmesi durumunda döndürülecek olan mesajlar hakkında da bilgi vardır.

Ayarlara ihtiyaç duyabilecek kaynaklara örnek olarak, BIOS'un yanı sıra NIC'ler ve depolama gibi cihazlar verilebilir.

Güncellenebilecek Özelliklerin Belirlenmesi

Hem Şema hem de meta veriler, hangi özelliklerin güncellenebileceğini tanımlar. "OData.Permissions/Read" olarak işaretlenen veya salt okunur özelliği TRUE olan özellikler, bu özelliklerin hiçbir zaman güncellenemeyeceğini belirtir.

Bunun yerine bir "OData.Permissions/ReadWrite" veya salt okunur özelliği FALSE ise yazılabilir olabileceğini belirtir.

LongDescription, hangi özelliklerin hangi koşullar altında yazılabilir olduğunu gösterebilir.

Varsayılan olarak, "İzinler" ek açıklaması olmayan meta verilerin veya salt okunur özelliği TRUE olmayan şemanın yazılabilir olduğu varsayılabilir.

Yazılabilir olarak işaretlenseler bile, uygulamalar özelliğin salt okunur olmasına izin verebileceğinden, bunun bir özelliğin yazılabileceği anlamına gelmediğini unutmayın.

Bir karmaşık tür özelliğine ilişkin izin, karmaşık tür içindeki "İzinler" ek açıklamasına sahip olmayan tüm özellikler için varsayılan izindir.

Örneğin, IPv4Address karmaşık türündeki SubnetMask özelliğinde "İzinler" ek açıklaması yoktur.

EthernetInterface içindeki IPv4Addresses özelliği, IPv4Address türündedir. IPv4Addresses bir "OData.Permission/Read" ek açıklamasına sahipse, SubnetMask salt okunur olur.

IPv4Addresses bir "OData.Permission/ReadWrite" ek açıklamasına sahipse, SubnetMask okuma-yazma türünde olur.

Anlaşılır olması için en iyi uygulama, karmaşık türdeki tüm özellikler için bir "İzinler" notu tanımlamaktır.

Redfish PUT/PATCH üzerindeki semantik öyledir ki, yazılamaz bir özelliği güncellemeye çalışmak bir hata olarak değerlendirilmez. Bir Redfish Hizmeti uygulaması, hangi özelliklerin güncellenemeyeceğini belirten Genişletilmiş Hata Bilgisi içeren bir 200 HTTP kodu döndürür.

Genişletilmiş Hata Yanıtı

Tek başına HTTP hata semantiği, kullanıcıların veya uygulamaların nedeni anlaması ve düzeltici önlem alması için yeterince bilgilendirici değildir, bu da bir Genişletilmiş Hata Yanıtı yapısı kavramına yol açar.

Genişletilmiş Hata Yanıtı yapısı ayrıca kayıt defterlerini destekler ve istemciler için daha anlamlı hata semantiği sağlar.

Örneğin, bir istemcinin aynı anda birkaç özelliği değiştirmek istediğini varsayalım. Ancak bunlardan biri geçersizdir.
Uygulama bir "400" döndürdüyse, istemcinin hangi özelliğin ve neden hatalı olduğunu anlamasına yardımcı olmaz. Veya bir "200" döndürürse ancak özelliklerden biri yoksa, bu anlamlı bir yanıt değildir.

Yanıta Genişletilmiş Hata Yanıtı içeren bir JSON gövdesi eşlik ediyorsa, yapı yalnızca döndürülen kodun nedenini değil, özellik adını ve hatta daha fazla bilgiyi içerebilir. ExtendedError bir mesaj dizisine sahip olduğundan, birden fazla sorunla karşılaşıldığında birden fazla mesaj döndürülebilir.

Olaylar (Events)

SNMP, IPMI ve diğer protokollerle uyum sağlamak için bir çeşit olay mekanizmasına ihtiyaç duyulduğundan zaten BMC'lerde var olan sistem kullanılmıştır.

Seçilen metodoloji, aboneliğe dayalı bir PUSH mekanizmasına dayalıdır. PUSH olayı, olay gönderildikten sonra hafızada kalıcı olmayacağı anlamına geldiğinden, BMC'ler için tercih edilir.

Bir istemcinin öncelikle, olayların gönderileceği olayları istediği URI'yi belirlemesi gerekir. EventSubscription koleksiyonuna bir POST isteği göndererek bir oturum kurulabilir.

Redfish iki farklı olay kategorisini destekler: "life-cycle"(yaşam döngüsü) ve "alert events"(uyarı olayları). Uygulama tarafından desteklenen olay türleri için EventService'e bakabilirsiniz.

Kullanıcı hesapları ve diğer kaynakları oluşturma

Eventing ve Sessions gibi, kaynaklar da bir POST işlemi aracılığıyla oluşturulur. Bu genellikle bir koleksiyona POST aracılığıyla yapılır.

Etkinlik aboneliği, oturumlar ve hesap hizmetlerinin tümü koleksiyonlara sahiptir. Bu koleksiyonun URI'si, bu hiper ortam API'sindeki diğer herhangi bir kaynak gibi keşfedilir.

Şema, bir istemcinin POST'ta hangi özelliklerin sağlanması gerektiğini belirlemek için kullanabileceği "RequiredOnCreate" adlı bir notu tanımlar.

Mesaj Uyumluluğu

Redfish tüm mesajlaşma formatlarına uyumlu halde tasarlanmıştır. Olay Mesajları, Genişletilmiş Hata Yanıtı Mesajları, Günlük Girişleri ve Mesaj Kayıtlarının tümü uyumludur.

Üreticiye özgü ve diğer biçimler bir uygulamada korunabilirken, yalnızca iletilerin yerelleştirilmesi değil, aynı zamanda depolamayı optimize etmeyi ve bu verilere erişen ve sunan hem istemci hem de hizmet görevlerini birleştirmeyi umarak, ileti biçimi hizalaması için ileriye dönük bir yol haritası vardır.

OEM

Redfish, üreticilerin "OEM" nesnesi içerisine kendi nesnelerini ekleyerek kendi uzantılarını dahil edebilmeleri için bir mekanizma tanımlamıştır. İstemcilerin şema dosyalarını bulabilmesi için bir "@odata.type" özelliğine sahip olması gerekir.

Uygulamalarda "OEM" adlı bu yapı 3 yerde oluşabilir: bir kaynağın temel özelliği olarak, "Bağlantılar" bölümünde veya "Eylemler" nesnesinde.

Bunun ötesinde standart, gereksinimler hakkında herhangi bir iddiada bulunmaz, ancak çok üreticili bir ortamın potansiyel olarak standart kaynakla aynı yapıya sahip uzantıları yerleştirebileceği bir mekanizmadır. Bu, daha fazla işlem ihtiyacını önler ve ölçeklenebilirliğe izin verir. Üreticilerin zaman içinde standardın bir parçası olacak yeni özellikler önermesi de beklenmektedir.

Güncel Entegrasyon ve Uyarlamalar

PowerShell