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

交換機や基地局といった通信(テレコム)のための専用設備は、 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...

 今回のNFV#39では、旧議長陣が引退し選挙が行われたり、次期NFVのコンセプトについてWorkshopがあったりと、ETSI NFVが大きく飛躍する期待を受けた。 NFV#39のサマリ NFVの各Releaseの概要は NFV IFA＆SOL(2021年10月)会合サマリとETSI NFV仕様の各リリース機能 、詳細は ReleaseDocument を参照して頂きたいが、前回 NFV#38 からの更新は Release2 (VNF LCMの基本機能): v2.8.1を最終バージョンとして終了(変化なし) Release3 (自動化やNWの制御): v3.7.1を最終バージョンとして最終メンテナンス中(WIM  IFを除く) SOL APIで参照しているREST系のRFCについて、RFC 9110 “HTTP Semantics”とRFC 8446 “TLS Version 1.3”によりいくつかの仕様が変更になった RFC 7231、RFC 7232、RFC 7233、RFC 7235が廃止(Obsoleted)されたことで、“payload body” -> “message content”、”422 Unprocessable Entity” -> “422 Unprocessable Content”と名称が変わった HTTP conditional requestsが導入され、GETやPatchでの”E-tag”や”Last-Modified”によるキャッシュの仕様が明確になった(既存仕様でも考慮はされていたが不透明な仕様だった) RFC 8446ではRFC 5246 “TLS Version 1.2”は廃止(Obsolted)になっているが、SOL  API Rel3はTLS 1.2を継続利用することになった SOL005 Os-Ma-NfvoにおけるImageのUpload/Download時にBASIC認証も利用できたが、OAuth2.0のみとなった SOL002 Ve-VnfmにおけるVNF/VNFC Configuration Dataにおいて、DHCP ServerのIP Addressは不要(DHCP DISCOVER/DHCP REQUESTはBroadcast)のため、dhcpServer a...

グローバル人材に向けて必要なスキルとは や 基礎情報収集 においてグローバルで必要となる知識やスキルについて紹介したが、今回はグローバルでチームを牽引するケースについて考えたい。 グローバルでチームを牽引する場合も、国内同様にステークホルダーを意識し、チームのアウトプット(作業スコープ)の明確化と作業全体の可視化は非常に重要であるが、それに追加して現作業のアウトプットが次の作業やプロジェクトに連続的に続くビジョンを描き続けることがチーム内のメンバーから信頼を得るためには重要だと感じる。 グローバルでチームを牽引するときのスキルセット グローバルであろうと、チームを牽引するためにはステークホルダー (お客様や依頼元、チーム内、幹部などの意思決定組織、自チームの作業の周辺作業のチーム等)からの“信頼“が必須となる。信頼を得るためには、スキルと実績が必要である。立場によるのかもしれないが、国内では実績に重きを置かれがちだが、海外ではスキルと与えられた権限に重きが置かれているように感じる。 ビジネススキルについては グローバル人材に向けて必要なスキルとは を参照して欲しいが、ビジネススキルのThink/Collaboration/Actionが揺らぐとなかなかチームを牽引することは難しい。これらのスキルスタックを基にステークホルダーから信用や信頼を得ることが、チームを牽引するスキルセットの第一歩となる。そして、リーダーとしてチームを牽引し続けるためには、お客様をはじめとした業務の依頼元との調整、チーム内の管理、そして自分自身のマインドセットの維持・向上を継続することが必要となってくる。 実はこれらのスキルセットや必要な能力は、実質国内の管理者やリーダー的存在のスキルセットと変わらない。しかし、各スキルや能力の濃淡には少し違いがある。例えば、グローバルではステークホルダーのバックグラウンドやモチベーションが異なるため、資本管理やメンバー管理といったマネジメントスキルより、ビジョンを掲げそのGAPを主張し続けられる人の方がリーダーとして信頼を得やすいように感じる。同様の背景から、反対意見を含む様々な意見や考えがある中でも最後までやり遂げられるタフさや、チームの活動内容を明確化するための作業スコープのIN/OUTを即時できる決断力を持った人が好まれる傾向にある気がする。 チームを...

  今回のNFV#38(5/30〜6/3)は久しぶりの現地(ETSI本部＠フランス・ニース近郊)となった。今回はOpenStack TackerもIFA/SEC/SOLもEnh01.01 Certificate Managementが一つの大きなトピックではあったが、それ意外もRelease4/5ともに 仕様検討が大きく進んだ。やはりFace To Faceの会議は、各社の意向を擦り合わせるのが難しい議論の進展には重要なのもかもしれない。 最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、現在のNFVのリリース機能の状況は NFV中間会合(10月)サマリ 、前々回のNFV会合の説明は NFV#36サマリ (NFV#37 2022年2月会合は筆者の執筆漏れ)を確認して頂きたい。 NFV#38のサマリ NFV#36やNFV#37と比較した重要な活動結果としては、 Release2はETSI-NFVとしてはv2.8.1を最終バージョンとしメンテナンスも終了 Release3はSOL019を除き、v3.6.1で既存仕様(Stage2/Stage3/Stage4)のReleae3対応は全て終了 Stage3/Stage4はv3.7.1のメンテナンスは継続 残仕様はFEAT10 (Multi-Site Connectivity Service)のSOL019 (MSCS Stage3) WIM向けIFの追加(v3.7.1(7月) or v3.8.1(12月)予定) Release4はdrop3としてv4.3.1のIFA/SOLの仕様が完成(Finalize中) Enh02.01 (SDN integration): Layer3のvRouter相当の記述をできるようにSOL001(NFV Descriptor)へRoutingResourceDataの追加 Enh02.02 (NS feasibility check): 時間のかかるNSのInstantiateの処理の前にInstantiateNSの事前チェック/リソース予約のためにSOL005(Os-Ma-Nfvo)へFeasibility Check/Reserveの追加 Enh02.03 (Data flow mirroring): VNFのTroubleshootingのための通信...