[Cloud] Traffic Management入門/Getting Started with Traffic Management

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/getting-started-with-traffic-management




先月の間に、Oracle Cloud InfrastructureではDynでの研究開発により、われわれの第二世代クラウドのネイティブ・エッジマネジメント能力に重要な機能強化をもたらすいくつかの新サービスをリリースしました。それらのサービスには以下が含まれています:
  • Traffic Management Steering Policies
  • Health Checks (Edge)
本日お話ししたいのは、エンタープライズ用途のグローバルに分散したアプリケーションサービスをTraffic Managementを使ってどのように構成し、制御し、最適化するかです。

前提条件

Traffic Management Steering Policiesを使う前提として、ドメイン(またはサブドメイン)をOracle Cloud Infrastructure DNSサービスの管轄下に置く必要があります。多くの組織ではサブドメインを特にソースサービスのグローバルロードバランシングを行わせる用途で管理させています(例:<service>.glb.domain.com)。詳細な情報はOverview of the DNS Serviceをご覧ください。
このポストでは例としてDNS経由で応答する pheatsols.com.au ドメインを使っています。

また、例の中ではふたつのApacheインスタンスをAshburnとLondonのリージョンに置いており、インスタンスの地理的な場所を記したシンプルなHTMLページを応答します。
 
直接IPアドレスを打ち込むと以下のメッセージが返ってきます:
 

シナリオ

上述のセットアップはふたつの地理的に分散した場所にサーバーがある(とても)ベーシックなWebアプリケーションを例としたものです。従来のDNSの構成では、ユーザーをこれらのアプリケーションにダイレクトする方法は限られており、また、それぞれ以下の制約がありました:
  • エントリーを分ける:サービスポイントごとにDNSエントリーを分けて作成(たとえばlondon.pheatsols.com.auashburn.pheatsols.com.au)してユーザーに近いほうを選ぶよう指示するやり方です。この方法では正しいサーバーを選ぶ責任をユーザー側に負わせるということになりますが、ユーザーエクスペリエンスは水準以下になってしまうでしょう。障害の際には、ユーザーに直接コミュニケーションしなければならないえすし、プログラムからのサービスアクセスも書き換えなければなりません。
  • 単一のエントリー:単一のDNSエントリーを作成(たとえばapplication.pheatsols.com.au)してこれをプライマリーサイトに向けておき、障害時や切り戻しの際にエントリーをマニュアルで更新するという方法です。この方法ではワークロードのバランシングはできません、つまり、Active-Passiveモードでの運用になります。障害時にDNSエントリーを更新しても伝播には多少時間がかかりますので、接続不能時間が伸びてしまうかもしれません。
  • ラウンドロビン:同じアドレスに対して複数のDNSエントリーを作成しておき、大まかに言うとルックアップごとに向けるサーバーを変えるDNSラウンドロビンを行わせる方法です。この方法ではノード障害が起きた場合、提供する接続がとぎれとぎれになってしまいます(リクエスト2回に1回は死んでいるノードにトラフィックを送ってしまう)。アプリケーションアーキテクチャによっては、ラウンドロビンではセッションの中で以前に接続していたサーバーとは違うサーバーに回されてしまい問題が起きるかもしれません。
理想としては、単一のDNSエンドポイントが、ユーザーリクエストをもっとも近いサーバーに自動的に転送し、しかしノード障害時には別の機能しているサーバーにシームレスにフェイルオーバしてくれることが望ましいでしょう。Traffic Management Steering Policiesにより(および密接に連携したHealth Checksサービスにより)まさにそれが実現できるのです。

Traffic Management Steering Policyの作成

まず始めに、Oracle Cloud Infrastructureのコンソールにログインします。ナビゲーションメニューからEdge Servicesを選択し、そしてTraffic Management Steering Policiesを選びます。


Create Traffic Management Steering Policyをクリックします。


Traffic Steering Policyの種類が表示されます。送信元の地理的な条件に応じて動的にリクエストをルーティングするGeolocation Steeringを選択しましょう(他の種類のPolicyについてはこのポストの後の章「Other Policy Types」で説明します)。


Policyの名前を入力し、TTL(Time To Live)を設定します。TTLはDNSサーバーが返信があったエントリーをキャッシュしておく期間を定義するものです。この値をアプリケーションのクリティカル性(TTLを低くすると、応答がないサーバーアドレスがキャッシュされている期間も短くなります)と、DNSサーバーの応答速度(TTLが短すぎるとDNSサーバーおよびクライアントはいつもクエリを名前解決しなければならなくなります)のバランスで決めます。この例ではデフォルトの60秒のままにしておきます。


次に、(この例においては)地理的な場所にもとづくサーバーグループであるAnswer Poolを定義していきます。この例では2つのプール、ashburnlondonがありそれぞれひとつのサーバーが属しています。もしそれぞれの場所に複数のサーバーがある場合は、あるサーバーがメンテナンス中でありトラフィックを流したくない際などに、そのサーバーを不適合としてマークしておくことができます。


いよいよここでGeolocation Steering Policyの設定をしていきます。ルールは上から下の順序でパースされます。この例では、Rule 1はNorth America、South America、OceaniaおよびAntarcticaからのトラフィックをAshburnにまずダイレクトし、Londonにフェイルオーバします(Geolocationは国のレベル、またUSとカナダについては州のレベルでも設定できます)。Rule 2ではAfrica、AsiaおよびEuropeのトラフィックをLondonにまずダイレクトします。Glocal Catch-all(いずれのルールもマッチしなかった場合に適用)はRule 1と同様の動きをさせます。


Health Checkを設定していきます。Health Checkはアクティブでないサーバーをプールから取り除き(また、オンラインに復帰した際にはプールに戻し)、"always available"アーキテクチャをサポートします。この例ではホストのルートアドレスの80番へのGETというベーシックなやり方ですが、追加のポート、パス、ヘッダやメソッドは定義可能です。


ポリシーをDNSエントリーに紐づけます。この例ではポリシーをapplication.pheatsols.com.auに適用しています。当該アプリケーションへの既存のスタティックなエントリーはこのダイナミックなポリシーによって置き換えられます。


最後に、Create Policyをクリック。ポリシーのサマリが表示されます。例ではPolicy Answer Dataセクションに両方のサーバーの状態がHealthyと表示されていますね。


ポリシーが作成できたので、テストしてみましょう。
私はオーストラリアに住んでいるので、application.pheatsols.com.auをブラウズする際にAshburnにダイレクトされるべきですが、その通りになっています。


フェイルオーバをテストするために、AshburnのApacheサービスを停止してみます。


すると、Policy Answer DataセクションにはAshburnがUnhealthyと表示されました。


そしてapplication.pheatsols.com.auをブラウズすると、シームレスにLondonにダイレクトされました。


大成功でした!

他のPolicy Typeについて

このポストではGeolocation Steeringにフォーカスしましたが、以下のTraffic Management Steering Policiesも利用可能です:
  • Load Balancer: バックエンドの複数のノードあるいはサーバー間で、重みづけした、Health Check付きのロードバランシングを行うことができます
  • Failover: シンプルな高可用性アーキテクチャをサポートするためのシーケンシャルな、Health Checkベースの応答を構成します
  • ASN Steering: トラフィックをその送信元のASNによって判別します(BGPルーティングで使われます)
  • IP Prefix Steering: 送信元のIPアドレス、レンジによってトラフィックを振り分けます

ユースケース

Traffic Management Steering Policiesのユースケースの実践は単純な高可用性構成やロードバランシングにとどまりません。今や以下のようなシナリオは、われわれの第二世代クラウドによって、よりシンプルにあるいはより強力に実現できます:
  • クラウドへの移行:重みづけされたロードバランシングにより、お客様データセンターからOracle Cloud Infrastructureサーバーへのコントロールされた移行をサポートします。まず少量のトラフィックをクラウドにダイレクトし、全てが想定通り動作していることを確認します。そしてトラフィックの割合を心配ない程度に増やしていき、最終的にすべてのトラフィックをクラウドに移行します。
  • ハイブリッド環境のサポート:Traffic Management Steering Policiesを使って、他のクラウドプロバイダやエンタープライズデータセンターなどパブリックな(インターネット上に公開され名前解決可能な)リソースであればいずれのものに向けてもトラフィックを転送することができます。
  • パイロットユーザーテスト:IP Prefix Steering Policyを使うことで、内部ユーザーと外部ユーザーに向けて異なるレスポンスを返すよう設定できます。
  • 地理による制限とパートナー限定アクセス:サービスへのリクエストをある地域に限定したり、パートナー組織に限定したりすることができます。catch-allとして「このコンテンツはお住まいの地域からは利用できません」を表示するよう設定する、などもできますね。
一連の統合されたEdgeサービスについてもっと知りたい場合は、ドキュメントリリースアナウンスメントを読んでみてください。

[Cloud] Regional SubnetとLoad Balancerを使った高可用性とフェイルオーバ/Using Regional Subnets and Load Balancers to Support HA and Failover

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/using-regional-subnets-and-regional-load-balancers-to-support-ha-and-failover




Oracle Cloud Infrastructureで複数のAvailability DomainをまたぐSubnetの構成を可能にする、Regional Subnetsが先月リリースされました。しかし、SubnetがRegionalであるということはどういう意味でしょうか?Oracle Cloud InfrastructureではもともとSubnetは単一のAvailability Domainでのみ構成できるよう設計されており、これはAvailability-Domain-SpecificなSubnetと呼ばれています。したがって、Subnetのリソースはある単一のAvailability Domain内に設置される必要がありました。しかし今ではRegionalなSubnetによって、Region内の複数Availability Domainにまたがってそのリソースを設置することができるようになったということです。Subnetを作成するときにタイプを選択することができます。Regional Subnetと新規/既存のAvailability-Domain-SpecificなSubnetはひとつのVirtual Cloud Network(VCN)内で共存させることができます。

Regional Private Load Balancerのご紹介

Regional Subnetのリリースと併せて、Private Load Balancerサービスがリージョン単位での高可用性を提供できるよう機能強化されました。Regional Subnetの搭乗前は、Private Load Balancerは単一のAvailability Domain内での冗長性しかなく、したがってLoad Balancerの可用性はそれが設置されたAvailability Domain自体の可用性に限定されていました。今回の機能強化により、Private Load Balancerはお客様は意識せずとも複数のAvailability Domainにまたがって高可用性を得られるようになりました。
次に記載する図はOracle Cloud Infrastructureのドキュメントから転載したもので、Availability-Domain-SpecificなLoad Balancerと新しいLoad Balancerの違いを説明しています。ひとつめの図では、CIDRレンジ10.0.4.0/24のPrivate SubnetがAD-2の中にのみ構成されており、したがってAD-2が完全にオフラインになってしまうといった障害に対しては耐性がありません。ふたつめの図では、同じPrivate Subnetが今回は3つのAvailability DomainをまたがるRegional Subnetとして構成されています。この構成ではLoad BalancerのIPアドレスが3つのAvailability Domainにまたがって利用可能になっています。
AD-2がオフラインになる障害が起きた場合にどのような差があるか考えてみましょう。ひとつめの図では、Load BalancerのIPアドレスもオフラインとなり、するとあなたのワークロードもリクエストの受付を停止してしまうことになるでしょう。しかし、ふたつめの図のようにRegional Load Balancerを利用していれば、プライベートIPアドレスは他のAvailability Domainに移動する、フェイルオーバするなどして、リクエストの受付を継続することができます。この機能によりLoad Balancerの可用性を高め、ワークロードの安定性を高めることができるというわけです。
注:既存の複数のAvailability-Domain-Specific Subnetで構成することで高可用性を得ているPublic Load Balancerは別のフェイルオーバモデルです。Regional Public Subnet内に作られたPublic Load Balancerは、ここでの説明と同様の冗長性を持つことになります。

ユースケース

ここで、ワークロードの可用性をRegional Subnetで高められる3つのシナリオを紹介していきます。

シナリオ1:Regional Private Load Balancer

Regional Load Balancerを構成する際、先にRegional Subnetを構成しておく必要があります(Availability-Domain-SpecificなSubnetにRegional Load Balancerを設置することはできません)。

ステップ1:Regional Subnetの作成

以下のスクリーンショットにあるように、Oracle Cloud InfrastructureでのSubnet作成時のデフォルト(推奨)オプションは現在、Regionalです。このオプションを選んだ場合、SubnetのAvailability Domainは選択しません。この点のみがRegional Subnetを作成する場合とAvailability-Domain-Subnetを作成する場合の違いです。
TerraformでRegional Subnetを設置する際には、Availability-Domain-SpecificなSubnetを設置する際とは違い、availability_domain の設定項目は不要です。以下のスクリーンショットの通りです。
注:既存のAvailability-Domain-Specific用のTerraformのコードからこの設定項目を除くとオペレーションを破壊してしまい、VNICが付与されたリソースを持つSubnet上では成功しません。
ぜひ試してみることをおすすめします。Terraformサンプル全量も参照してみてください。

ステップ2:Regional Load Balancerの作成

Load Balancerを作成するためのRegional Subnetの作成が済んだので、Regional Load Balancerを作成していきましょう。
以下のスクリーンショットにある通り、SubnetフィールドにRegional(Recommended)セクションが追加されています。Availability-Domain-Specificサブネットを選ぶのではなく、新しく作成したRegional Subnetを選択しましょう。
Terraformでオペレーションする場合には、テンプレートの修正は不要です。単にあるRegionalなSubnetを選択することで、RegionalなLoad Balancerとして作成されます。
これらのステップを実行することで、Regional SubnetにRegional Load Balancerを構成することがえきます。続けて、Regional Subnetが効果を発揮するもうひとつの代表的なシナリオを見ていきましょう。

シナリオ2:異なるAvailability Domainのインスタンス間のIPフェイルオーバ

ロードバランシングに加えて、多くのアプリケーションやソリューションが仮想的な「浮遊する」IPアドレスのフェイルオーバというコンセプトを取り入れています。このようなシナリオでは、クラスタリングされたマシンがハートビートによって接続されており、フェイルオーバメカニズムはあるIPをアクティブなノードの移り変わりに応じて割り振ったり戻したりします。Regional Subnetの搭乗前には、フェイルオーバオペレーションの差異にこの仮想的なIPアドレスを同一のSubnetの中のインスタンスの間のみで移動させることができました。現在では、いずれのAvailability Domainにあるインスタンスの間でも、プライベートIPアドレスを移動することができるようになったのです。
このデザインにより、仮想IPアドレスフェイルオーバを用いながらアプリケーションをAvailability Domainをまたいで冗長に構成することができます。たとえば、Pacemaker、CorosyncとOracle Cloud Infrastructureを使ったクラスター内のふたつのインスタンスの間で仮想IPを移動させることができます。Automatic Virtual IP Failover on Oracle Cloud Infrastructureのブログポストをご覧ください。

まとめ

このポストではRegional SubnetとRedional Subnetをご紹介し、Oracle Cloud Infrastrucuture上でフェイルオーバアーキテクチャを強化する方法について解説しました。VCNのドキュメントを読み、さらに詳しく学んでみることをおすすめします。また、リリースノートも公開されています。
このポストを楽しんでいただけたようであれば幸いです。ご承知でしょうが、全てのOracle Cloud Infrastructureのテナントにはエンタープライズグレードのサポートが含まれていますから、お客様はこうしたサービスにアクセスするためにサービスリクエストを起こすことができますよ。製品チームにフィードバックをシェアしたい場合は、feedback_oci_virtual_networking@oracle.comにemailを送ってください。

[Cloud] Cloud SyncでStorage Gatewayを最大限活用/Get the Most Out of Storage Gateway with Cloud Sync

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/get-the-most-out-of-storage-gateway-with-cloud-sync







Oracle Cloud Infrastructure Storage GatewayのCloud Sync機能はふたつのNFSサーバー間でのファイル同期を可能にしてくれます。
以前のわたしのブログポストで、Oracle Cloud Infrastructure上で稼働するよう作られたObject StorageベースのNFSサーバーであるStorage Gatewayをご紹介しました。このソリューションはデータ転送、バックアップおよびアーカイブのユースケースにぴったりです。また、クラウドネイティブではないソフトウェアがObject Storageバケットのオブジェクトをどのように取り出したり書き込んだりするかを意識せずにObject Storageを使えるようにしてくれます。
しかし、あなたのアプリケーションが高頻度で大規模なファイル書き込みを行うようなものだったとしたらどうでしょう?このようなケースでは、Storage Gatewayに直接書き込みを行うやり方はあまり実践的ではありません。外部のクラウドリソースからのファイル読み込み、書き込みには時間がかかりますから、高速なストレージを必要とするアプリケーションをスローダウンさせてしまうでしょう。一方で、あなたはObject Storageを使うことで得られる事実上無限のストレージ容量を欲しています。このような場合に一般的なソリューションには、ふたつのNFSサーバーを稼働させることが含まれています;ひとつは高速なBlock Volumeベースのものにしておいて、アーカイブ用にはObject Storageベースのものを使う、というやつです。そして、もしローカルNFS上のファイルをStorage Gateway上のファイルと同期できたら便利です。これをマニュアルで行うこともできるでしょうが、ヒューマンエラーの可能性が怖いですよね。であればCloud Syncを使うこともできますよ。

Cloud Syncとはなんぞや

Storage GatewayのCloud Sync機能は、Linux標準のrsyncコマンドを用いてローカルのNFSサーバー上のファイルをObject StorageベースのStorage Gateway NFSサーバーへの同期、またその逆の同期を行うものです。さらに、このツールはエラーハンドリングと進捗のモニタリングも行います。この機能はメタ―自動ジョブ(たとえば夜間cronジョブ)を行うもので、スクリプトに加えたりすることなく使えるためとても簡単にできます。接続の問題は自動リトライでシームレスに対処され、Webコンソールとコマンドラインインターフェース(CLI)のどちらで起動してもステータスフィードバックを提供します。高いレベルでの自動化を行うには、出力をCLIでモニタリングしておくことが理想的でしょう。
でもちょっと待ってください…これだけではありません!CLIのパラメータからわかるように、Cloud Syncは人間がほとんどいつも失敗してしまうタスクであるファイルのパラレル同期を行ってくれます:
sudo ocisg cloudsync create [--auto-delete] [--parallel=<number>] [--files-from=<file>] <job_name> <source_path> <target_path>
ジョブを作成し、パラレル処理するプロセスの数(最大10まで)を指定し、実行するだけでいいのです:
sudo ocisg cloudsync run <job_name> 
ローカルNFSサーバーからStorage Gatewayに大きなデータを転送したいような場合に特に、この機能が役立ちます。もしかしたらあなたは数テラバイトのデータをObject Storageに移動しようとしているかもしれません。Cloud Sync機能を使うことで、1日数十テラバイトのデータを扱うこともできるようになります。自動リトライと再開機能により、人による干渉は必要なくなります。
わたしはいつもCLIを使うことをおすすめしていますが、Webコンソールでも高速で直観的、便利にClous Syncジョブを作成し、実行し、参照し、削除することができますよ。
このOracle Cloud Infrastructureの新機能についての記事を楽しんでいただけたなら幸いです。ではまた次回お会いするときまで、クラウドであれ!

[Cloud] VirtualBox VMのOracle Cloud Infrastructureへのインポート/Importing VirtualBox Virtual Machines into Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/importing-virtualbox-virtual-machines-into-oracle-cloud-infrastructure



大きな企業では多くの種類のOSを使っているものです。Oracle Cloud Infrastructureは新しいもの古いもの両方の様々なOSをサポートしています。また、お客様がオンプレミス環境のOracle VM、VMware、KVM、そして今日ではさらにVirtualBoxなどのさまざまなソースから、rootボリュームをインポートすることをサポートしています。

VirtualBoxはエンタープライズ向けのパワフルなx86およびAMD64/Intel64の仮想化プロダクトです。このブログポストと関連するビデオであるImporting VirtualBox Virtual Machines to Oracle Cloud Infrastructureでは、VirtualBoxでSUSE Linux 15仮想マシン(VM)を作成し、それをインポートするのに必要なステップを解説していきます。この手順は既存のVMにも適用可能なもので、Oracle Cloud Infrastructureへの"move and improve"移行が簡単に行うことができます。

VirtualBox VMの作成

まずシンプルなVirtualBox VMを作りましょう。詳細はビデオをご覧くださいね。繰り返しますが、この手順は既存のVMにも適用可能ですよ。

VirtualBox VMのインポートの準備

クラウドで起動できるよう、VMのイメージがインポートできるようになっているか確認しましょう。イメージは以下の要件を満たしている必要があります:
  • 300 GiB未満
  • マスターブートレコード(MBR)を含んでいる
  • (UEFIではなく)BIOSを使うよう設定されている
  • 単一ディスク
  • VMDKまたはQCOW2ファイルである
このポストで扱っている例は、openSUSE Leapをデフォルトセッティングでインストールしたものです。
また、インスタンスのセキュリティ設定がクラウド環境として適切であるかも確認してください。たとえばファイアウォールが有効であり、秘密鍵認証を利用するSSHログインのみが許可されている、などです。カスタムイメージの条件についてもっと詳細が知りたい場合は、Bring Your Own Custom Image for Paravirtualized Mode Virtual Machinesの"Custom Image Requirements"の章をチェックしてください。
必要に応じて、以下のタスクも実施してください:
  • のちのトラブルシュートのために、インスタンスにシリアルコンソールインターフェースを追加しておく
  • KVM paravirtualizedドライバの追加
  • プライマリNICにDHCPの設定をする

シリアルコンソールの有効化

イメージの設定の確認後に、必要に応じて、のちのVMのトラブルシューティング用にシリアルコンソールを有効化します。
  1. /etc/default/grubファイルを開き、以下のように更新します:
    • resume= は起動時間をかなり長くするので、カーネルパラメータから削除します
    • GRUB_TERMINAL="gfxterm" を GRUB_TERMINAL="console serial" に書き換え、シリアルコンソールを使うようにします
    • GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200" を追加し、grubのシリアル設定を行います
    • GRUB_CMDLINE_LINUX="" を GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200" に書き換え、シリアルコンソールをLinuxカーネル起動パラメータに追加します
  2. initramfs を以下のコマンドで再作成します:
    grub2-mkconfig -o /boot/grub2/grub.cfg
  3. 念のためマシンを再起動し、dmesg を実行して更新したカーネルパラメータをチェックしましょう:
    dmesg | grep console=ttyS0
これらの準備についての詳細は、Preparing a Custom Linux Image for Importの"Enabling Serial Console Access"の章をご覧ください。

Paravirtualizedの有効化

次に、VMのinitrd にvirtioドライバを構成することで、paravirtualizedデバイスサポートを追加しましょう
  1. この操作はLinuxカーネルバージョン3.4以降でしか有効でないため、システムのカーネルバージョンが新しいことをチェックしましょう:
    uname -a
  2. initrd を dracut ツールでリビルドし、qemu モジュールを追加させましょう:
    dracut --logfile /var/log/dracut.log --force --add qemu
  3. lsinitrd tをチェックし、virtioドライバが存在することを確認しましょう
    lsinitrd | grep virtio
詳細はdracut(8)lsinitrd(1)のマニュアルをご覧ください。

ダイナミックネットワーク接続の有効化

次に、VirtualBox内では利用できていたインターフェースをVMが使い続けようとすることがないように、永続化されたネットワーク接続設定をクリアしておきましょう。
以下のコマンドで 70-persistent-net.rules ファイルの中身を空にします(ファイル自体は消去しません):
> /etc/udev/rules.d/70-persistent-net.rules
注意:この変更はVMが再起動されるとリセットされます。インポートする前にVirtualBox内でVMを再起動した場合は、このステップをもう一度実施する必要があります。
詳しくはudev(7)のマニュアルとPredictable Network Interface Namesを参照くださいませ。

VMの電源停止

準備ができたら以下のようにインスタンスを停止しましょう:
halt –p
これでVMは準備完了です。

イメージのアップロード

VMの電源をオフにしたら、あなたのPC上からObject StorageへとVMディスクをコピーしましょう。あなたのPCにはOracle Cloud Infrastructure CLIをインストール、設定しておく必要があります。初めて行う場合にはCLI Quickstartをご覧ください。
ファイルをアップロードするにはOCI CLIを使いましょう。Object StorageのWebコンソールは2GiB以内のファイルしかサポートしておらず、これはちょっとイメージのアップロードには使えそうにありません。イメージが十分に小さかったとしても、CLIでアップロードするほうがぜんぜん速いです。
  1. Oracle VM VirtualBoxマネージャのウィンドウで、VM indexを開きます。
  2. 目的のVMを右クリックし、Show in Finderを選択します。VMディスクのディレクトリパスとファイル名を控えておきます。
  3. ターミナルを開き、VMのディレクトリパスとファイル名、およびOracle Cloud Infrastructureのテナンシーネームスペース、Object Storageバケット名を指定してアップロードします:
    VM_DIR="/Users/j/VirtualBox VMs/openSUSE-Leap-15.0/"
    VM_FILE="opensuse-leap-15.0.vmdk"
    NAMESPACE="intjosephholsten"
    BUCKET_NAME="images"
    
    cd "${VM_DIR}"
    oci os object put -ns "${NAMESPACE}" -bn "${BUCKET_NAME}" --file "${VM_FILE}"
アップロードにはイメージのサイズとネットワーク帯域によってはいくらか時間がかかります。
アップロードに関してさらに詳しく知りたい場合、Managing ObjectsでObjectバケットへのアップロードに関するCLIの使い方を見てください。

イメージのインポート

アップロードが完了したら、Oracle Cloud Infrastructureコンソールにログインしてイメージをインポートしましょう。
  1. イメージをアップロードしたバケットの詳細ページに行き、イメージの詳細を開いてURLを調べましょう。このURLは後で使います。
    VM Image URL in the Object Details console
  2. ナビゲーションメニューからCompute、そしてCustom Imagesを選択します。
  3. Import Imageをクリックします。
    paravirtualizedドライバを使えるようにしておいた場合は、paravirtualizedモードを選んでおくことで最高のパフォーマンスが得られます。
    Select Launch Mode: Paravirtualized in the Instance Create dialog
インポートプロセスがスタートし、しばらくすると完了します。
詳細な情報はImporting Custom Linux-Based Imagesをご覧ください。

インスタンスへのアクセス

イメージのインポートを終えたら、image detailsのページから直接インスタンスを起動できるようになります。
Create Instance button on Image Details page
インスタンスが起動したら、そのパブリックIPアドレス、およびVirtualBoxでの稼働時に使っていたものと同じ認証情報を用いてSSH接続しましょう。
Successful ssh connection, with Public IP field on Instance Detail page in background
VirtualBox VMをOracle Cloud Infrastructureへのインポートを完了できました!
あなたもやってみてください。 Oracle Cloudアカウントをまだお持ちでない場合は、http://cloud.oracle.com/tryitでフリートライアルに登録しましょう!

[Cloud]Oracle Data Caching Cloud Serviceの発表/Announcing Oracle Data Caching Cloud Service

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-data-caching-cloud-service



Oracleはサンフランシスコで開催されたRedisConf2019で、エンタープライズ企業がRedisを構築し、運用するためのOracle Data Caching Cloud ServiceのLimited Availability(LA)リリースを発表しました。
Oracle Data Caching Cloud ServiceはOracle Cloud Infrastructure上で提供されるマネージド、シングルテナントのRedis-as-a-service(Redis-aaS)です。ネイティブの実行環境で稼働し、コンソール、REST API、CLI、SDKおよびTerraform経由で管理することができます。Oracle Data Caching Cloud Serviceによって、様々なデータ構造をサポートし、多くの場合クラウドネイティブアプリケーションとともに用いられるポピュラーなオープンソースのインメモリ分散Key-ValueデータストアであるRedisを利用するメリットを、インフラや複雑な運用の管理の手間なしに享受することができます。

Pay-Per-Use

Oracle Data Caching Cloud Serviceの課金体系とパッケージングは、シンプルで柔軟なモデルとなっています。お客様はキャッシュインスタンスが起動され、稼働している時間だけ課金されます。Pay-per-useにより、Oracle Data Caching Cloud Serviceは開発、テストおよび本番の様々なワークロードにとって理想的なプラットフォームとなっています。インスタンスの使用料は、シンプルな課金体系、すなわちキャッシュメモリ GB/hour によって測られます。

Open Source

オープンソースソフトウェアは開発者たちがソフトウェアを組み上げる方法を劇的に進歩させてきました。モダンなクラウドネイティブアプリケーションの開発プラットフォームの様々なコンポーネント――コンテナやKubenetes、キャッシング、SQL/NoSQL DB、ELKなど――がオープンソースプロジェクトとして開発されたものです。マネージドRedis-aaSをOracle Cloud Infrastructureの主要サービスとして提供することが示しているのは、開発者たちがパワフルなクラウドネイティブアプリケーションをOracle Cloud Infrastructure上で開発、稼働できるようにするために、付加価値つきのオープンソースソリューションにわれわれが注力しているということです。

Caching for Cloud

キャッシングは業務アプリケーションやクラウドサービスを構築するうえで、基礎となるコンポーネントです。Oracle Data Caching Cloud Serviceは、Oracle Cloud Infrastructure上でクラウドネイティブアプリケーションを、RedisをインメモリKey-Valueストアとして利用して構築しようとする開発者たちをターゲットとしています。Redis application tierのデプロイには、ComputeやContainer Engine for Kubernetes、Oracle Functionsなどのサービスがとりわけ向いているでしょう。
データベースのキャッシングもOracle Data Caching Cloud Serviceにとって重要なユースケースのひとつです。Autonomous Transaction Processingや、Database Cloud Service、MySQLやComputeサービス上で稼働する他のデータベースインスタンスのフロントエンドとしてキャッシングを用いることで、データアクセス速度を改善したり、データベースの処理をオフロードすることができるでしょう。

Enterprise Grade

他のOracle Cloud Infrastructureネイティブサービスと同様に、Oracle Data Caching Cloud Serviceはエンタープライズグレードのセキュリティ、パフォーマンス、可用性および管理性を備えています。Identity and Access Management(IAM)ポリシーにより、テナンシーやコンパートメントのユーザーに対してOracle Data Caching Cloud Serviceの権限を必要に応じて割り当てることができます。
さらに、どのVirtual Cloud Network(VCN)にOracle Data Caching Cloud Serviceのインスタンスがプロビジョニングされるかを予め設定しておくことができます。それぞれの新規インスタンスごとに、必要なデータキャッシング容量に応じて、キャッシュのシェイプを選択することができます。また、プライマリーとレプリカのRedisノードがそれぞれどのVCNの/どのアベイラビリティドメイン(AD)の/どのサブネットにプロビジョニングされるべきかも定義しておくことができます。Oracle Data Caching Cloud Serviceのインスタンスは、ひとつのプライマリRedisノードと、オプショナルな4つまでのレプリカノードから構成され、すべてを単一のアベイラビリティドメインで稼働させることも、単一リージョンの配下の複数のアベイラビリティドメインに分散させることもできます。
サービスインスタンスのヘルスおよびパフォーマンス情報はインスタンスモニタリングページから参照することができ、メトリックによりOracle Data Caching Cloud Serviceの主要なオペレーショナルデータをフィルタしたレポートが利用できます。

Getting Started

Oracle Data Caching Cloud Serviceは2019年後半にGA(Generally Available)となる予定です。現時点では、Cloud Native Limited Availability Programを通じ、何社かの限定されたお客様にお願いしてサービスの評価をしていただいているところです。Oracle Data Caching Cloud Serviceについてもっと詳しく知りたい、また、使ってみたいというお客様は、oracle.com/cloud-native/で登録をお願いします。Oracle Data Cloud Serviceのベースとなっているオープンソーステクノロジーについて学びたい場合は、redis.ioを訪ねてみるとよいでしょう。

[Cloud] Oracle CloudでGitを使ってみよう/Getting Started With Git On Oracle Cloud

原文はこちら。
https://blogs.oracle.com/developers/getting-started-with-git-on-oracle-cloud




Oracle Cloud Infrastructureコンソールの中から新しい、改善されたOracle Marketplaceが使えるようになりました。Marketplaceではソースコントロール、バグトラッキングやCI/CDアプリケーションなどのプロジェクトの中で開発者が一般に使えるアプリケーションが提供されており、そしてどんどん追加されていきます。Marketplaceの最も素晴らしいところは、こうしたツールが稼働するインスタンスを1クリックで作れるところです。それではここから、ほとんどすべてのソフトウェアプロジェクトで使われるソースコントロールツールの、さらにその中でも最もポピュラーなものであるGitを使うインスタンスの作り方をご覧に入れましょう。

Gitを使いはじめるには、まずOracle Cloudコンソールの左側のメニューからMarketplaceを選びましょう:

Marketplaceで'GitLab CE Certified by Bitnami'を選びます:


以下のページで'Launch Instance'をクリック:


イメージとコンパートメントを選び、条件を確認して承諾したら、'Launch Instance'をクリックしましょう:


もし既にOracle Cloudでインスタンスを作ったことがあれば、次のページは見慣れたものでしょう。インスタンス名を入力し、インスタンスシェイプとネットワーク設定を選びましょう。のちほど使うことになるSSHキーをアップロードするのも忘れないでくださいね。確認できたら'Create'をクリック:


インスタンスのプロビジョニングが始まり、詳細ページに遷移します。  


インスタンスのプロビジョニングの間に、選んだサブネットに、インスタンスがWebからアクセスできるようにセキュリティとルートテーブルが正しく設定されていることを確認しましょう。サイドバーから'Networking'→'Virtual Cloud Networks'を選択します:



Virtual Cloud Networkの初期ページから、ネットワークを作成する際に選択したVCNを選び、そして以下のようなページで選んだサブネットを確認しましょう。これで確認あるいは作成したいルールに直接ナビゲートすることができるようになりました:



まずインターネットゲートウェイに来る全インカミングトラフィックのルートテーブルルールを確認(あるいは作成)します:


次に、セキュリティリストでポート80番、443番への全てのインカミングトラフィックが許可されていることを確認しましょう(この際、このサブネットがWebに暴露したくない他のインスタンスに関連付けられていないことを確認してください):


このあたりまでであなたのGitLabインスタンスのプロビジョンが完了しているでしょう。インスタンス詳細ページ(サイドバーからCompute→Instances)に行き、GitLabインスタンスの詳細を表示します。パブリックIPアドレスをメモしておいてください:


左のメニューから'Console Connections'をクリックし、'Create Console Connection'のダイアログを開き、インスタンスを作成したときに使ったSSHキーを選択して'Create Console Connection'をクリックしましょう:


これでhttp://<public ip>のURLでブラウザからGitLabの管理者を使うことができるようになりました:


デフォルトのユーザー名は'root'です。初期パスワードを知るためには、インスタンスに次のコマンドでSSHアクセスします:
ssh bitnami@<public ip> -i /path/to/ssh_key

初期パスワードは'bitnami_credensials'というファイルに格納されています。参照するには:
cat ./bitnami_credensials

以下のように表示されるでしょう:

ログインしてGitLabをOracle Cloudで使い始めましょう!