Synapse AnalyticsのSQLプールでは、ユーザー指定でのメンテナンススケジュールが設定できるようになっています。
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/maintenance-scheduling/
ただし、DWUが400c以下の場合には、占有リソースにならないこともあり、指定したメンテナンススケジュール通りにはならないことがあります。これは上記のドキュメントにも記載されています。
なお、DWUが400c以下の場合にはメンテナンススケジュールが設定できなくなっているため、どうしても設定したい場合には一度DWUを500c以上に上げてメンテナンススケジュールを設定したのち、DWUを400c以下に変更してください。
繰り返しになりますが、この場合はメンテナンススケジュール通りにメンテナンスされる保証はありません。
2020年4月27日月曜日
2020年4月14日火曜日
Ubuntu 18.04LTSにMinikubeをインストールする手順
様々なパブリッククラウドでKubernetesのマネージドサービスが出てきており、すぐにKubernetesを使える環境が得られるようになっていますが、一から作った環境で調査するのも有用な場合があります。ここでは、1台のPC上に仮想的にKubernetesの環境を構築できるMinikubeの環境構築手順を記述します。なお、OSはUbuntu 18.04LTS、ハイパーバイザーとしてはKVMを使います。
Visualizationのチェック:
以下のコマンドを実行します。何かしら出力されればOKです。
kubectlのインストール:
Hypervisor(KVM)のインストール:
KVM2ドライバーのインストール:
Minikubeのインストール:
Minikubeの起動: 一旦minikube deleteコマンドを実行したほうがよいです。
Visualizationのチェック:
以下のコマンドを実行します。何かしら出力されればOKです。
$ grep -E --color 'vmx|svm' /proc/cpuinfo
kubectlのインストール:
$ sudo apt-get update && sudo apt-get install -y apt-transport-https $ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - $ echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list $ sudo apt-get update $ sudo apt-get install -y kubectl
Hypervisor(KVM)のインストール:
$ sudo apt install libvirt-clients libvirt-daemon-system qemu-kvm
KVM2ドライバーのインストール:
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2 && sudo install docker-machine-driver-kvm2 /usr/local/bin/
Minikubeのインストール:
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_1.8.1-0_amd64.deb \ && sudo dpkg -i minikube_1.8.1-0_amd64.deb
Minikubeの起動: 一旦minikube deleteコマンドを実行したほうがよいです。
$ minikube delete $ minikube start
2019年3月28日木曜日
C#でasync Mainメソッドを使いたいとき
C# 7.1からasync Mainメソッドが使えるようになったので、Mainメソッドから直接非同期メソッドをコールできるようになりました。
ただし、Visual Studioでデフォルトの設定だとビルドの言語バージョンが「C#の最新のメジャー バージョン (既定)」になっており、この場合C# 7.0を指している場合があります。
ビルド実行時に「エントリ ポイントに適切な静的 'Main' メソッドを含んでいません」というエラーが出る場合はこれにあたっているため、ビルドの言語バージョンで具体的なC#のバージョンを指定するか、「C#の最新のマイナー バージョン (最新)」を選択してみてください。
ただし、Visual Studioでデフォルトの設定だとビルドの言語バージョンが「C#の最新のメジャー バージョン (既定)」になっており、この場合C# 7.0を指している場合があります。
ビルド実行時に「エントリ ポイントに適切な静的 'Main' メソッドを含んでいません」というエラーが出る場合はこれにあたっているため、ビルドの言語バージョンで具体的なC#のバージョンを指定するか、「C#の最新のマイナー バージョン (最新)」を選択してみてください。
2019年1月22日火曜日
Bot Framework v4で、App ServiceにデプロイするとInternalServerErrorが出る現象について
Bot Framework v4でEmulatorでは通常に動作するものの、App ServiceにデプロイしてアクセスするとInternalServerErrorが出ることがあります。
こちらの現象について、4.1.5のバージョンでは以下の対処にて解決できました。
1..botファイルの修正
Visual StudioでBotアプリのプロジェクトを開くとxxx.botというファイルがありますが、こちらのservicesのエントリを以下のように記述してください。本来はApp Serviceのアプリケーション設定でアプリケーションIDやパスワードを設定するはずなのですが、これがうまく動作していないようです。
2. ライブラリを以下で指定(これは細かいバージョンによって異なる可能性があります)
・ターゲットフレームワーク:.NET Core 2.1
・Microsoft.Bot.xxx -> 4.1.5
・Microsoft.AspNetCore、Microsoft.AspNetCore.All -> 2.1.6
こちらの現象について、4.1.5のバージョンでは以下の対処にて解決できました。
1..botファイルの修正
Visual StudioでBotアプリのプロジェクトを開くとxxx.botというファイルがありますが、こちらのservicesのエントリを以下のように記述してください。本来はApp Serviceのアプリケーション設定でアプリケーションIDやパスワードを設定するはずなのですが、これがうまく動作していないようです。
"services": [
{
"type": "endpoint",
"appId": "<アプリID>",
"appPassword": "<パスワード>",
"endpoint": "https://<デプロイしたApp ServiceのURL>/api/messages",
"id": "<ボットID>",
"name": "production"
},
{
"type": "endpoint",
"appId": "",
"appPassword": "",
"endpoint": "http://localhost:3978/api/messages",
"id": "2",
"name": "development"
}
],
2. ライブラリを以下で指定(これは細かいバージョンによって異なる可能性があります)
・ターゲットフレームワーク:.NET Core 2.1
・Microsoft.Bot.xxx -> 4.1.5
・Microsoft.AspNetCore、Microsoft.AspNetCore.All -> 2.1.6
2018年9月18日火曜日
SQL Datababse Migration InstanceのIOPSの考え方
SQL ServerをAzure上に配置する場合、ディスクごとにIOPSのキャップがかかるので、データファイルを複数のディスクに分散配置させることでパフォーマンスを向上させることができます。
SQL Database Managed Instanceの場合はこれとは異なり、Premium Storageがデータファイルごとに使われるため、データファイルごとにIOPSのキャップがかかります。このため、データファイルの数やサイズの設計を考える必要があります。
Premium StorageはP10~P50が使われ、データファイルの大きさに従って動的に切り替わります。例えばデータファイルの大きさが100GBの場合はP10が使われるため、IOPSのキャップは500になります。大きさが200GBになるとP10のサイズは128GBであるためP20に切り替わり、IOPSのキャップが1100になります。
データファイルのサイズが小さくなる場合も同様の動きになります。例えば、200GBのデータファイルが100GBに縮小された場合、P20からP10に切り替わり、IOPSのキャップは500になります。
SQL Database Managed Instanceの場合はこれとは異なり、Premium Storageがデータファイルごとに使われるため、データファイルごとにIOPSのキャップがかかります。このため、データファイルの数やサイズの設計を考える必要があります。
Premium StorageはP10~P50が使われ、データファイルの大きさに従って動的に切り替わります。例えばデータファイルの大きさが100GBの場合はP10が使われるため、IOPSのキャップは500になります。大きさが200GBになるとP10のサイズは128GBであるためP20に切り替わり、IOPSのキャップが1100になります。
データファイルのサイズが小さくなる場合も同様の動きになります。例えば、200GBのデータファイルが100GBに縮小された場合、P20からP10に切り替わり、IOPSのキャップは500になります。
2018年8月20日月曜日
自分のPCからAzure DCへの通信速度を計測する方法
自分のPCのブラウザから、Azureの各データセンターへの通信速度が計測できます。
地方にお客様がいる場合、どこのデータセンターが近いかを確認できますね。
http://azurespeedtest.azurewebsites.net/
地方にお客様がいる場合、どこのデータセンターが近いかを確認できますね。
http://azurespeedtest.azurewebsites.net/
2018年7月25日水曜日
Azure Active DirectoryのExpressRouteサポートが変わったようです
以下、結構要注意なので備忘録を兼ねて。
ExpressRouteでPublicピアリングやMicrosoftピアリングを有効にして利用している環境では、Azure ADに対する認証トラフィックがExpressRouteを経由していました。
これが 2018 年 8 月 1 日から次のように変更されます。
Microsoftピアリング、かつExpressRouteを利用するサービスとして“その他のOffice 365 Onlineサービス (12076:5100)”のBGPコミュニティを利用するように構成されている場合のみExpressRouteを経由する。
ただし、2018/5/1現在ではサポートリクエストをあげることにより利用可能となっているようです。
詳細は以下のURLを参照してください。
https://blogs.technet.microsoft.com/jpazureid/2018/07/19/azuread-expressroute/
ExpressRouteでPublicピアリングやMicrosoftピアリングを有効にして利用している環境では、Azure ADに対する認証トラフィックがExpressRouteを経由していました。
これが 2018 年 8 月 1 日から次のように変更されます。
Microsoftピアリング、かつExpressRouteを利用するサービスとして“その他のOffice 365 Onlineサービス (12076:5100)”のBGPコミュニティを利用するように構成されている場合のみExpressRouteを経由する。
ただし、2018/5/1現在ではサポートリクエストをあげることにより利用可能となっているようです。
詳細は以下のURLを参照してください。
https://blogs.technet.microsoft.com/jpazureid/2018/07/19/azuread-expressroute/
登録:
投稿 (Atom)