I am thinking you would make the ListVolumeStats API call to the SF cluster
from a management server because we know that management servers should have
access to the management network of the SF cluster. I know some KVM hosts might
have access to the management network of the SF cluster that supports their
volumes, but they don't have to: KVM hosts (and hypervisor hosts in general)
only need access to the storage network of the SF cluster that supports their
volumes. If the agent happened to be running on a KVM host that only has access
to the storage network, then this agent can't make the ListVolumeStats API
call. As such, I think the ListVolumeStats API call should be executed from a
management server.
You are correct that the volumes_details tables contains the ID of a SolidFire
volume.
I don't know all of the ways a volume can transition from the Ready state to
some other state. I would not rely on the volume's state in the DB to determine
if a VM is having trouble accessing a volume.
On 6/8/20, 2:47 PM, "Sven Vogel" <s.vo...@ewerk.com> wrote:
NetApp Security WARNING: This is an external email. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
Hi Paul, Hi Mike, Hi Syed,
@Paul
> Doesn’t the same problem exist with that? If the agent dies, then the
fake volume will stop being updated but the VMs would still be running.
Do you mean we don’t know if a machine is running and get an false
positive? I think about if we had only one fake volume and if they are not
there so we would get an fencing of the host and kill all machines. Maybe the
other volumes are accessible.
I see different challenges.
1. SF uses normally a storage network so with that if the management
network is down don’t means the volumes are not accessible.
2. A Fake volume can produce false positives maybe this one is due too any
reason will not accessible but the other ones can be achieved
@Mike
> Since you know which (SolidFire) volumes are connected to a particular
KVM host, I would think you could just use the ListVolumeStats API (described
below) from a management server to determine if there is disk activity to any
of those volumes.
You mean the work would be done not from the Agent but from the management.
You mean we should periodically check the "ListVolumeStats“ on the Solidfire
from the Management Server and know if they are active.
What I see is that in the „volume_details“ table are all SF volumes are
listed. Right? They are connected with the „volumes“ table and there I will
finde the „instance_id“. Now there are two ways. Find about the „vm_instance“
table the if the instance is „running“, I think this is important and „host_id“
I don’t know if the „volumes“ table „ready“ state is useful. This will give
us a „ready“ state but does not mean its active. I hope I am correct.
@Paul
If this is thinkable where is a best way to implement it that it works. I
mean what I need to enable that i know HA is working but lacking on the storage
heartbeat.
1. How I need to configure HA that it will work?
2. I read the documentation from Rohit and found that he wrote "For the
initial release, only KVM with NFS storage will be supported. However, the
storage check component will be implemented in a modular fashion allowing for
checks using other storage platforms(e.g. Ceph) in the future.“ Where is a good
way In the code to start so won’t implement it wrong and lets more focused on
finalizing? Maybe you can clarify it a little bit.
Cheers Sven
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
s.vo...@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
EWERK-Blog | LinkedIn | Xing | Twitter | Facebook
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen
Dank.
The contents of this e-mail (including any attachments) are confidential
and may be legally privileged. If you are not the intended recipient of this
e-mail, any disclosure, copying, distribution or use of its contents is
strictly prohibited, and you should please notify the sender immediately and
then delete it (including any attachments) from your system. Thank you.
