1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
\r
2 .. http://creativecommons.org/licenses/by/4.0
\r
4 =============================
\r
5 Configuration and Performance
\r
6 =============================
\r
7 The DataFile Collector (DFC) gets fileReady messages from the Message Router (MR) sent from xNFs, via the VES Collector.
\r
8 These messages contains data about files ready to get from the xNF. DFC then collects these files from the xNF and
\r
9 publishes them to the DataRouter (DR) on a feed. Consumers can subscribe to the feed from DR and process the file for
\r
10 its specific purpose. The connection between a file type and the feed it will be published to is the
\r
11 **changeIdentifier**. DFC can handle multiple **changeIdentifier**/feed combinations, see picture below.
\r
13 .. image:: ../../images/DFC_config.png
\r
19 By default, DFC handles the "PM_MEAS_FILES" change identifier and publishes these files on the "bulk_pm_feed" feed.
\r
20 But it can also be configured to handle more/other change identifiers and publish them to more/other feeds. The
\r
21 configuration of DFC is controlled via a blueprint.
\r
23 Blueprint Configuration Explained
\r
24 """""""""""""""""""""""""""""""""
\r
26 For the communication with the Message Router, the user must provide the **host name**, **port**, and **protocol** of
\r
27 the DMaaP Message router.
\r
29 .. code-block:: yaml
\r
30 :emphasize-lines: 2,6,10
\r
35 description: dmaap messagerouter host
\r
36 default: message-router.onap.svc.cluster.local
\r
39 description: dmaap messagerouter port
\r
43 description: dmaap messagerouter protocol
\r
46 The user can also specify which version of DFC to use.
\r
48 .. code-block:: yaml
\r
54 description: DFC image tag/version
\r
55 default: "nexus3.onap.org:10001/onap/org.onap.dcaegen2.collectors.datafile.datafile-app-server:1.2.0"
\r
57 The user can also enable secure communication with the DMaaP Message Router.
\r
59 .. code-block:: yaml
\r
65 description: enable certificate based connection with DMaap
\r
68 DFC can handle multiple change identifiers. For each change identifier/feed combination the user must provide the
\r
69 **change identifier**, **feed name**, and **feed location**.
\r
71 **Note!** The **feed name** provided should be used by the consumer/s to set up the subscription to the feed.
\r
73 The **feed name** and **feed location** are defined as inputs for the user to provide.
\r
75 .. code-block:: yaml
\r
76 :emphasize-lines: 2,6
\r
81 description: The name of the feed the files will be published to. Should be used by the subscriber.
\r
82 default: "bulk_pm_feed"
\r
85 description: The location of the feed.
\r
88 The **feed name** shall be used in the definition of the feed for the DMaaP plugin under the "**node_templates**"
\r
89 section under a tag for the internal "**feed identifier**" for the feed (feed0 in the example).
\r
91 .. code-block:: yaml
\r
92 :emphasize-lines: 1,5
\r
95 type: ccsdk.nodes.Feed
\r
98 get_input: feed0_name
\r
101 The **feed location** shall be used under the **streams_publishes** section under a tag for the internal
\r
102 "**feed identifier**" for the feed.
\r
104 .. code-block:: yaml
\r
105 :emphasize-lines: 2,4
\r
110 get_input: feed0_location
\r
113 The **change identifier** shall be defined as an item under the **streams_publishes** tag in the "**application_config**"
\r
114 section. Under this tag the internal "**feed identifier**" for the feed shall also be added to get the
\r
115 info about the feed substituted in by CBS (that's what the <<>> tags are for).
\r
117 .. code-block:: yaml
\r
118 :emphasize-lines: 4,5
\r
120 application_config:
\r
124 dmaap_info: <<feed0>>
\r
127 And, lastly, to set up the publication relationship for the feed, the "**feed identifier**" must be added to the
\r
128 "**relationships**" section of the blueprint.
\r
130 .. code-block:: yaml
\r
131 :emphasize-lines: 3
\r
134 - type: ccsdk.relationships.publish_files
\r
137 Sample blueprint configuration
\r
138 """"""""""""""""""""""""""""""
\r
140 The format of the blueprint configuration that drives all behavior of DFC is probably best described using an example.
\r
141 The blueprint below configures DFC to handle the two feeds shown in the picture above.
\r
143 .. code-block:: yaml
\r
148 description: dmaap messagerouter host
\r
149 default: message-router.onap.svc.cluster.local
\r
152 description: dmaap messagerouter port
\r
156 description: dmaap messagerouter protocol
\r
160 description: DFC image tag/version
\r
161 default: "nexus3.onap.org:10001/onap/org.onap.dcaegen2.collectors.datafile.datafile-app-server:1.2.0"
\r
164 description: number of instances
\r
168 description: enable certificate based connection with DMaap
\r
174 description: The name of the feed the files will be published to. Should be used by the subscriber.
\r
175 default: "bulk_pm_feed"
\r
178 description: The location of the feed.
\r
182 description: The name of the feed the files will be published to. Should be used by the subscriber.
\r
183 default: "log_feed"
\r
186 description: The location of the feed.
\r
189 datafile-collector:
\r
190 type: dcae.nodes.ContainerizedServiceComponentUsingDmaap
\r
192 cloudify.interfaces.lifecycle:
\r
198 application_config:
\r
200 dmaap.security.enableDmaapCertAuth: { get_input: secureEnableCert }
\r
201 streams_subscribes:
\r
205 { concat: [{ get_input: dmaap_mr_protocol },"://",{ get_input: dmaap_mr_host },
\r
206 ":",{ get_input: dmaap_mr_port },"/events/unauthenticated.VES_NOTIFICATION_OUTPUT/OpenDcae-c12/C12"]}
\r
209 dmaap_info: <<feed0>>
\r
212 dmaap_info: <<feed1>>
\r
215 get_input: tag_version
\r
216 service_component_type: datafile-collector
\r
220 get_input: feed0_location
\r
224 get_input: feed1_location
\r
227 - type: ccsdk.relationships.publish_files
\r
229 - type: ccsdk.relationships.publish_files
\r
232 type: ccsdk.nodes.Feed
\r
235 get_input: feed0_name
\r
238 type: ccsdk.nodes.Feed
\r
241 get_input: feed1_name
\r
244 .. _strict_host_checking_config:
\r
246 Turn On/Off StrictHostChecking
\r
247 ------------------------------
\r
248 **StrictHostChecking** is a SSH connection option which prevents Man in the Middle (MitM) attacks. If it is enabled, client checks HostName and public key provided by server and compares it with keys stored locally. Only if matching entry is found, SSH connection can be established.
\r
249 By default in DataFile Collector this option is enabled (true) and requires to provide known_hosts list to DFC container.
\r
251 **Important: DFC requires public keys in sha-rsa KeyAlgorithm**
\r
253 **Known_hosts file** is a list in following format:
\r
255 .. code-block:: bash
\r
257 <HostName/HostIP> <KeyAlgorithms> <Public Key>
\r
261 .. code-block:: bash
\r
263 172.17.0.3 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDRibxPenQC//2hzTuscdQDUA7P3gB9k4E8IgwCJxZM8YrJ2vqHomN8boByubebvo0L8+DWqzAtjy0nvgzsoEme9Y3lLWZ/2g9stlsOurwm+nFmWn/RPnwjqsAGNQjukV8C9D82rPMOYRES6qSGactFw4i8ZWLH8pmuJ3js1jb91HSlwr4zbZZd2XPKHk3nudyh8/Mwf3rndCU5FSnzjpBo55m48nsl2M1Tb6Xj1R0jQc5LWN0fsbrm5m+szsk4ccgHw6Vj9dr0Jh4EaIpNwA68k4LzrWb/N20bW8NzUsyDSQK8oEo1dvsiw8G9/AogBjQu9N4bqKWcrk5DOLCZHiCTSbbvdMWAMHXBdxEt9GZ0V53Fzwm8fI2EmIHdLhI4BWKZajumsfHRnd6UUxxna9ySt6qxVYZTyrPvfOFR3hRxVaxHL3EXplGeHT8fnoj+viai+TeSDdjMNwqU4MrngzrNKNLBHIl705uASpHUaRYQxUfWw/zgKeYlIbH+aGgE+4Q1vnh10Y35pATePRZgBIu+h2KsYBAtrP88LqW562OQ6T7VkfoAYwOjx9WV3/y5qonsStPhhzmJHDF22oBh5E5tZQxRcIlQF+5kHmXnFRUZtWshFnQATBh3yhOzJbh66CXn7aPj5Kl8TuuSN48zuI2lulVVqcv7GmTS0tWNpbxpzw==
\r
265 HostName could also be hashed, e.g:
\r
267 .. code-block:: bash
\r
269 |1|FwSOxXYeJyZMAQM3jREjLSIcxRw=|o/b+CHEeHuED7WZS6sb3Y1IyHjk= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDRibxPenQC//2hzTuscdQDUA7P3gB9k4E8IgwCJxZM8YrJ2vqHomN8boByubebvo0L8+DWqzAtjy0nvgzsoEme9Y3lLWZ/2g9stlsOurwm+nFmWn/RPnwjqsAGNQjukV8C9D82rPMOYRES6qSGactFw4i8ZWLH8pmuJ3js1jb91HSlwr4zbZZd2XPKHk3nudyh8/Mwf3rndCU5FSnzjpBo55m48nsl2M1Tb6Xj1R0jQc5LWN0fsbrm5m+szsk4ccgHw6Vj9dr0Jh4EaIpNwA68k4LzrWb/N20bW8NzUsyDSQK8oEo1dvsiw8G9/AogBjQu9N4bqKWcrk5DOLCZHiCTSbbvdMWAMHXBdxEt9GZ0V53Fzwm8fI2EmIHdLhI4BWKZajumsfHRnd6UUxxna9ySt6qxVYZTyrPvfOFR3hRxVaxHL3EXplGeHT8fnoj+viai+TeSDdjMNwqU4MrngzrNKNLBHIl705uASpHUaRYQxUfWw/zgKeYlIbH+aGgE+4Q1vnh10Y35pATePRZgBIu+h2KsYBAtrP88LqW562OQ6T7VkfoAYwOjx9WV3/y5qonsStPhhzmJHDF22oBh5E5tZQxRcIlQF+5kHmXnFRUZtWshFnQATBh3yhOzJbh66CXn7aPj5Kl8TuuSN48zuI2lulVVqcv7GmTS0tWNpbxpzw==
\r
273 To provide known_hosts list to DFC, execute following steps:
\r
275 1. Create file called known_hosts with desired entries.
\r
277 2. Mount file using Kubernetes Config Map.
\r
279 .. code-block:: bash
\r
281 kubectl -n <ONAP NAMESPACE> create cm <config map name> --from-file <path to known_hosts file>
\r
285 .. code-block:: bash
\r
287 kubectl -n onap create cm onap-dcae-dfc-known-hosts --from-file /home/ubuntu/.ssh/known_hosts
\r
290 3. Mount newly created Config Map as Volume to DFC by editing DFC deployment. **DFC deployment contains 3 containers, pay attention to mount the file to the appropriate container.**
\r
292 .. code-block:: yaml
\r
304 - image: <DFC image>
\r
308 - mountPath: /home/datafile/.ssh/
\r
309 name: onap-dcae-dfc-known-hosts
\r
314 name: <config map name, same as in step 1, e.g. onap-dcae-dfc-known-hosts>
\r
315 name: onap-dcae-dfc-known-hosts
\r
318 Known_hosts file path can be controlled by Environment Variable *KNOWN_HOSTS_FILE_PATH*. Full (absolute) path has to be provided. Sample deployment with changed known_hosts file path can be seen below.
\r
320 .. code-block:: yaml
\r
332 - image: <DFC image>
\r
334 - name: KNOWN_HOSTS_FILE_PATH
\r
335 value: /home/datafile/.ssh/new/path/<known_hosts file name, e.g. my_custom_keys>
\r
339 - mountPath: /home/datafile/.ssh/new/path
\r
340 name: onap-dcae-dfc-known-hosts
\r
345 name: <config map name, same as in step 1, e.g. onap-dcae-dfc-known-hosts>
\r
346 name: onap-dcae-dfc-known-hosts
\r
349 To change mounted known_hosts list, edit existing Config Map or delete and create it again. **The DFC container may refresh changes with a delay.** Pod, nor container restart is NOT required.
\r
351 To edit Config Map execute:
\r
353 .. code-block:: bash
\r
355 kubectl -n <ONAP NAMESPACE> edit cm <config map name>
\r
359 .. code-block:: bash
\r
361 kubectl -n onap edit cm onap-dcae-dfc-known-hosts
\r
363 To delete and create again Config Map execute:
\r
365 .. code-block:: bash
\r
367 kubectl -n <ONAP NAMESPACE> delete cm <config map name>
\r
368 kubectl -n <ONAP NAMESPACE> create cm <config map name> --from-file <path to known_hosts file>
\r
372 .. code-block:: bash
\r
374 kubectl -n onap delete cm onap-dcae-dfc-known-hosts
\r
375 kubectl -n onap create cm onap-dcae-dfc-known-hosts --from-file /home/ubuntu/.ssh/known_hosts
\r
378 To turn off StrictHostChecking, set below option to false. It could be changed in DCAE Config Binding Service (CBS).
\r
380 **WARNING: such operation is not recommended as it decreases DFC security and exposes DFC to MitM attacks.**
\r
382 .. code-block:: bash
\r
384 "sftp.security.strictHostKeyChecking": false
\r
390 To see the performance of DFC, see "`Datafile Collector (DFC) performance baseline results`_".
\r
392 .. _Datafile Collector (DFC) performance baseline results: https://wiki.onap.org/display/DW/Datafile+Collector+%28DFC%29+performance+baseline+results
\r