英語が苦手でもグローバル人材を目指して

今回のNFV#43はTM Forumとco-located(同日同会場開催)だったため、普段と異なる参加者がいた。また、Future NFVについては継続的に議論した。 NFV#43のサマリ NFVの各Releaseの概要は NFV IFA＆SOL(2021年10月)会合サマリ と ETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument 、各仕様の最新状況は Openbox と Feature Wiki を参照して頂きたい。 前回 NFV#42 からの更新は Release4(コンテナ対応): v4.5.1のFinalize化 v4.5.1: コンテナ関連とセキュリティ関連の仕様改善 SOL016 MANO Procedureのコンテナ＆セキュリティ対応 最低限のPaaS管理(PaasServiceInfo&PaasServiceHandler)を仕様化 FEAT31(Flexible VNF deployment)のうちDeployableModuleを仕様化  TST010のv4.3.1のFinalize化( Robot code ) FEAT17 (Clust-native) : SOL020 CCMのFinalize化 Container based VNFの制御に関する仕様はStage3までほぼ完了 CIS Cluster (コンテナ基盤)制御のためのCCM(SOL020)についてCluster APIをベースにStage3終了 FEAT20 (Autonomous):  IFA050 (Intent mgmt)の基本IFとしてStage3(SOL021)開始 Intent + Data Analyticsによって運用の自動化のためのIFを規定中 MANOの中にデータ分析機能である IFA047 (MDAF: Management Data Analytics Function)のStage2が発行済 Intentは3GPP  TR 28.812  /  TS 28.312 やTM Forum TMF921A, ETSI ISG  ZSM011 にて制定済であり、それらと整合化済 NFVの当初思想は仮想リソース(Compute/Network/Storage)をNet...

 今回のNFV#42はFuture NFVという名目で、ETSI NFVを含むETSIの標準化やOpen Sourceとの関わり方を含めた組織のあり方についてのキックオフがあった。 NFV#42のサマリ NFVの各Releaseの概要は NFV IFA＆SOL(2021年10月)会合サマリ と ETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument 、各仕様の最新状況は Openbox と Feature Wiki を参照して頂きたいが、前回 NFV#41 からの更新は Release4(コンテナ対応): v4.5.1のStable化 v4.5.1: コンテナ関連とセキュリティ関連の仕様改善 DaemonSetの定義  TST010のv4.3.1のStable化( Robot code ) FEAT17 (Cloud-native) : SOL020のGAP分析終了 -> Stage3開始 Container based VNFの制御に関する仕様はStage3までほぼ完了 CIS Cluster (コンテナ基盤)制御のためのCCM(SOL020)についてGAP分析が完了し、Cluster APIをベースにStage3開始 FEAT19 (NFV Connectivity):  NFVにおけるネットワーク関連の仕様としてVM系( IFA035 )とコンテナ系( IFA038  発行済) IFA035もStable化済 FEAT20 (Autonomous):  IFA050 (Intent mgmt)の基本IF策定 Intent + Data Analyticsによって運用の自動化のためのIFを規定中 MANOの中にデータ分析機能である IFA047 (MDAF: Management Data Analytics Function)のStage2が発行済 Intentは3GPP  TR 28.812  /  TS 28.312 やTM Forum TMF921A, ETSI ISG  ZSM011 にて制定済であり、それらと整合化済 NFVの当初思想は仮想リソース(Compute/Network/Storage)をNetwork Serviceという...

交換機や基地局といった通信(テレコム)のための専用設備は、 ITとモバイルの保守の違いとは？ のように全国に大規模分散される傾向があるため、現地に行く頻度を最小化するために遠隔でハードウェアのリセットや起動等ができるような高度なOAM(Operation Administration Maintenance)が実装されていた。NFV(Network Function Virtualization)の普及によって、昨今の通信設備は仮想化技術を利用してソフトウェア化された通信設備と、安価な汎用サーバや汎用NW機器を集めて利用するリソースプールで構成されるようになってきており、リソースプール化された物理装置群をいかに効率的に保守できるかが肝となってきている。 リソースプールで利用される汎用サーバはDELLやHPEのようなサーバベンダが有名がであるが、データセンタの復旧によってBMC(Baseboard Management Controller)と呼ばれる遠隔保守のためのボードが搭載されるようになった。今回はハードウェアの故障検出の特徴を復習しながら、テレコムのHWの保守方法がどのように変わってきているか確認したい。 ハードウェアの障害検出方法 『 PC(パソコン)ハードウェア 初心者の館 』が分かりやすいが、ハードウェアはCPUを中心にChipsetを経由して様々な部品(コンポーネント)と接続された機器である。Chipsetとコンポーネントを接続できるカードをマザーボードと呼び、マザーボードはストレージ、ネットワークカードと接続されハードウェアは構成される。特にデータセンタで利用されるようなサーバでは、マザーボードのCPUとは独立して動作するようなOAMカードもハードウェアに搭載されることが多い。 CPUは各コンポーネントのDriverを経由して各コンポーネントの障害を検知し、BMCはセンサーによって各障害を検知している。BMCは各サーバベンダが独自のOAMカードを提供しており、HPEはiLO、DELはiDrac、IBMはIMMと呼ばれている。 テレコムにおけるハードウェア監視のトレンド 専用装置の時代では、テレコムの設備はシステム毎にハードウェア監視機能が存在していた。主にOAM機能を保有したソフトウェアが常駐し、そのOAM機能部が各種障害情報を集め、OAMのネットワ...

今回のNFV#41はNFV10周年イベントがあり、様々なオペレータや団体からのプレゼンテーションがあった。 NFV#41のサマリ NFVの各Releaseの概要は NFV IFA＆SOL(2021年10月)会合サマリ と ETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument 、各仕様の最新状況は Openbox と Feature Wiki を参照して頂きたいが、前回 NFV#40 からの更新は Release4(コンテナ対応): v4.4.1がFinalizeされ、v4.5.1(Stage2はラストバージョン)に向けてRelease4残機能の仕様策定を開始 v4.4.1: コンテナ関連とセキュリティ関連の仕様改善 Containerに関わるVirtualCP(KubernetesのService IP相当)に関する仕様の改善(LBに対応) OAuthのScope値の定義 (SOL002/SOL003/SOL005) ObsoleteになったRFCの更新 (Payload body -> message contentに変更) DaemonSetのSOL018への定義 (VNFDはv4.5.1へ延期) Containerに関するMANO Procedure (SOL016)の作成 (v4.4.1では完了せずv4.5.1へ延期) TST010のv4.3.1のWI開始 FEAT17 (Clust-native): SOL020のGAP分析開始 CCMのStage 3のデファクトソリューションとして、Cluster API, Terraform, Kubespray, Crossplane, TackerをStage2のCCM仕様とのGAP分析 -> PMとGrantをサポートしているソリューションがTacker以外無いが、TackerはCCDをサポートしていないため要継続検討 FEAT19 (NFV Connectivity):  NFVにおけるネットワーク関連の仕様としてVM系( IFA035 )とコンテナ系( IFA038  発行済)を検討中 IFA035にL3VPNとしてMP-BGPの追加 (Stable間近) FEAT20 (Autonomous): IFA050 (Intent mgmt)の基本IF策定 ...

RESTをはじめとした最近のフレームワークや実装では、データベース(DB)やストレージはシステムの中の実装オプションの一例というレベルではなく非常に存在感を増した技術になってきている。一方で、DBやストレージはデータを破損させないように非常に多岐に渡る技術が蓄積されているため、なかなか理解するのにハードルが高い。そこでDBとストレージを勉強する上での入り口になるように概要を説明してみたい。厳密には正しくない部分があるが、分かりやすさ重視のため、その点はご了承頂きたい。 システム開発のフレームワークとデータの関係 突き詰めるとプログラムとは何か？システムとは何か？というと、与えられた 情報 を元に、定められた ロジック によって、問題を解決するもの、である。最初は暗号解読や天気予報など特定の問題を解決するために使われてきたが、段々プログラム言語が開発されプログラムが汎用化されたり、ハードウェアの性能が上がって問題解決のパワーが増したことで、解決できる問題のバリエーションも量も激増してきた。その結果、システム開発の定石(フレームワーク)も変わってきた。 システム開発のフレームワークには様々な評価軸があるが、ここでは問題解決のスケールとして、データ量と処理量に着目してみたい。初期のプログラムはテープにデータとルーティン処理が記録された専用計算機だったものが、プログラムの汎用化とハードウェアの高性能化によって、①扱うデータが増えたことでデータベース化する流れと、②処理量が増えたことに対するマルチプロセス化という2つの流れができる。その結果、一昔前の典型的なフレームワークとしては、データは全てストレージ＋データーベスへ格納しデータの管理に特化したプログラムと、そのデータを加工する処理ロジックに特化したプログラムに分離する流れができた。 しかし、このアーキテクチャは、ストレージのサイズやDBの性能にボトルネックが来たり、処理ロジックが変更になった時に他のロジックへの影響も含めて見直しが必要だったりして、問題(＝要件)の変化に追従し続けるメンテナンスも大変だった。特にデータ量を拡張したり処理量を拡張する場合は、大型サーバのスケールアップ(CPUやメモリやディスクを増やす)が主な方法となっておりコストも増加した。そこで、データとロジックを一つのオブジェクトとして隠蔽し、オブジェクト...

 9月の会合から段々と現地参加型の会合の形式に変わってきた。オンライン参加者もまだまだ多く今回10月のO-RANと12月のNFV#40は現地とオンラインのハイブリッドでの開催ではあるが、概ねどこの企業も最低でも数名は現地で参加しているようだ。HuaweiやZTE等の中国企業も代表者は現地で参加していた。 今回のNFV#40はLayer123との同時開催となり、様々なグローバル動向の議論があった。そのNFV、O-RAN、Layer123の議論を聞く限り、昨今の方向性は"コンテナ化"から"統一プラットフォーム + 自動化"になってきているように感じる。 NFV#40のサマリ NFVの各Releaseの概要は NFV IFA＆SOL(2021年10月)会合サマリ と ETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument 、各仕様の最新状況は Openbox と Feature Wiki を参照して頂きたいが、前回 NFV#39 からの更新は Release2(v2.8.1)に続き、Release3(v3.7.1)もメンテナンス終了となってきた。WIMのStage 3 IF Or-Wi( SOL019 )は完成しなかったため、Release4へ延期となる。 新ETSI NFV ISG議長中島さんのChairman perspectiveが発表された Release4(コンテナ対応): 4.4.1に向けてCIS Cluster管理のためのCCM (CIS Cluster mgmt)を中心にStage2/3の仕様化 FEAT17 (Clust-native): CCMのStage3 IFとしてSOL020が提案＆承認された CIS Cluster (Kubernetes Master Node + Worker Node)を構築＆運用する機能部としてCIS Cluster Management Function (CCM)が定義 CCMはCIS ClusterのLCMやFCAPS、更にはKubernetesのCRD(Custom Resource Definition)も構築＆管理する IFA036のアーキテクチャや機能分担を満たせるデファクトソリューションはないため、GAP分析からスタート Cluster AP...