这是一个公平的问题，拉克什。 答案隐藏在细节中。 据我所知，Google本身并未将BareMetal产品归类为云基础架构的一部分。 而且Oracle从未提到GCP作为受支持的基础架构-至少据我所知。 从AWS和Azure来看，从他们的角度来看，只有Oracle Cloud是受支持的IaaS环境：

http://www.oracle.com/us/ Corporate/pricing/cloud-licensing-070579.pdf

从SAP的角度来看，将我们的软件堆栈（应用程序服务器/数据库实例）拆分给不同的基础架构供应商绝对是没有道理的，也不支持。 例如，这在SAP注释 1380654

中记录

用于操作SAP软件解决方案的所有紧密耦合的运行时组件的整个基础结构（包括计算，网络和存储组件）是单个基础结构提供者的责任。 这特别但非排他地适用于数据库服务器和应用程序服务器。

将这些详细信息放在一起，SAP无法为我们不拥有的应用程序提供支持声明。 在这种情况下，GCP不支持Oracle DBMS，因此，SAP的我们当然不能支持这种组合。 如果将BareMetal实例视为私有基础结构，则客户（如果可以通过硬件本身的认证）可以在那里运行应用程序，就像他能够在自己的数据中心中操作该软件一样。

希望有帮助。

最好，山姆

谢谢山姆。 抱歉，我可能对上面的单词选择有误。 当我指的是在GCP上为Oracle支持SAP工作负载时，我的意思是在这里与Oracle的政策保持一致（这是Google博客中精心阐述的内容）。 它在colo设置中提到" ..close to Google Cloud"（不在Google Cloud上）。

在所示的设置中：

（a）裸机本身不是GCP Cloud的一部分（但托管在GCP Cloud的附近）（如Google博客所述），我想它符合Oracle的"授权云环境"政策-即它不是 在公共云上，但有效地托管在类似于本地托管的裸机服务器上。

（b）鉴于它采用的是Google博客所述的colo设置，因此仍然属于1380654所规定的条件的定义（您已突出显示"单一基础设施供应商"的特定框）。

鉴于托管显然可以分别满足Oracle和SAP的上述（a）和（b）要求，就涉及的解释而言，托管确实可以满足要求，但我仍然认为这是SAP需要解决的问题 应该检查以帮助数十名针对Oracle运行工作负载的SAP客户。