Greetings,
Long term data is (currently) on the NFS, though if I could figure out how to
do it effectively in K8s, I wouldn't put it there either. For the generating
Config info, they include Certificates and other sensitive Security
Information. I suggest local Container Node persistence for a couple of
reasons.
* An NFS, in my opinion, may very well be configured badly, and allow for
security issues.
* NFS is Network Drive. if access is interrupted, and ALL AAF Instances
require it, then ALL AAF is down. If ALL AAF is down, then all ONAP is down.
* I consider this security infrastructure to be Mission Critical, when
used, so I avoid as many catastrophe generating implementations as possible.
* A local Drive on the Node is much less likely to fail, and if it does,
and there are multiple nodes, AAF keeps going
* Certificates, and configurations (including Geo Location) is better on
Node basis, if possible.
* Nodes are more isolated, less easy to get to
* If a Node has a problem, such as letting a Cert Expire, other Nodes
may well cover traffic if theirs aren't expired, allowing for better Resiliency
* AAF's "Locator" architecture allows you to put AAF "nodes" anywhere in
the world, allowing for localized access for fastest possible access time,
which is critical, given it is Security. I suspect an NFS drive would negate
that advantage, forcing what COULD be an Independent Node in Singapore to talk
to what may be US Based NFS drive for DB data storage. That is unacceptable,
imho.
Future instances of ONAP, I hope to figure out how to do Cassandra in K8S
startups reasonably fast, so they can be Per Node as well, giving the kind of
Global Scalability and Resiliency that AAF already provides as Standalone VMs
for my company.
--
Jonathan Gathman
Principled-System Architect
ATO Tech Dev/SEAT/Platform Architecture and Technology Management
AT&T Services, Inc.
m 314-550-3312 | [email protected]
On 8/9/19, 8:32 AM, "[email protected] on behalf of Andrew Fenner"
<[email protected] on behalf of [email protected]> wrote:
Hi,
On an el-alto staging install my aaf didn't come up.
After a bit of digging I found that the file
/opt/app/osaaf/local/org.osaaf.aaf.cassandra.props was missing and that
this was mapped from /mnt/data/aaf/config/local/
After a bit of cleanup and restarts the problem went away so I put it
down to one of the wierd issues that happens. If it happens again I'll
try to get to the bottom of it and raise a jira.
But the question is why the aaf isn't using the /docker-nfs directory
for this data as it makes it very hard to debug and unpredicatable as
the /mnt/data/aaf/config directory is local to each k8s host.
Is there a reason for this ?
Thanks
/Andrew
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18504): https://lists.onap.org/g/onap-discuss/message/18504
Mute This Topic: https://lists.onap.org/mt/32810443/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
