[Autogenerated] it is having a rough week.
Two separate times, people were
complaining about a deadness outage and
each time had its own clues to find the
culprit. Let's do some troubleshooting.
We're here a Jaden's computer and will
start a fresh trace file. Both he and
Gabriella have been receiving reports off
slowdowns and accessing the internet, so
he's going to go ahead and try to capture
his own traffic to see if he sees the same
thing. We'll go ahead and import the
profile to his computer. Jaden's
configuration is to go to the stub server
for DNA's, so we'll start a fresh capture
on that server. Jaden opens up his browser
and goes to www dot Globomantics dot com.
It does take a little bit before the
web page starts to load, and that's a big
clue that it's DNA SAP. He'll go out to
app Pluralsight com that one seems to load
faster. Let's see how sales does well,
that loaded right away. But what? We need
to see the packets to determine if it's a
DNA's problem. Some of the addresses could
have been in cache. Jaden wants to make
sure that the primary server is up
because, remember, the stub server pulls
its data from the primary and secondary.
The primary is up, but the secondary seems
to have a challenge. And remember, with
the primary, just because it's up doesn't
mean that DNA is working properly for the
secondary. The reason that it doesn't
respond is because the firewall is set not
to allow pinks. Great from a security
standpoint. Not so great from a
troubleshooting standpoint. Let's check
the primary server. We know it's up, but
how's it SSHD nested status? Uh huh.
Apparently someone stopped the DNA service
on the primary. Now, An s secondary is
doing the job of both the primary and the
secondary. So we've just doubled the load
on the secondary. Not to mention remember,
our clients go to the primary first, wait
for a response before they try the
secondary. That adds latency as well.
We'll leave. The service stopped for the next demo.