Need to know if there are built-in or suggested minimum time limits for AAD Connect synchronization. I have a customer asking to set synchronization to 1 minute, but aside from being a bad idea, I want to know if there are programmatic constraints for this.
The minimum allowed is 30 minutes. You can set AllowedSyncCycleInterval but it cannot go lower than that.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-scheduler
You can force a sync but if you do that too often, AD Connect will initiate a forced cool off and wait 30 minutes anyway. And even if you force it, there will be 5-10 minute delays depending on what you are waiting for.
Here is what you can use to force it, though it is not really recommended to go lower than the 30 minute default for the reasons mentioned.
Invoke-Command -ComputerName <Host> {Import-Module ADSync; Start-AdSyncSyncCycle -PolicyType Delta}
Related
If someone malicious gets access to ACCOUNTADMIN, sets DATA_RETENTION_TIME_IN_DAYS=0 to all objects in a database and then start destroying these objects, does Snowflake provide a means to rebuild the database as it was before the attack? Time Travel should not be available anymore.
From my understanding, Failsafe kicks in only after Time Travel, so if Time Travel was set to 90, then from what I understand the best we can hope for is gaining back data that is 90 days old.
What to do to prevent this kind of scenario?
This is what Fail Safe is for. As soon as the malicious attack sets everything to 0 data retention, all of your data would be available in Fail Safe. You have 7 days before that data is removed. You would lose your time-travel for that 90 days, though.
I'm developing my first App Engine Flexible Environment application.
The docs explain that virtual machines are restarted weekly:
VM instances are restarted on a weekly basis. During restarts
Google's management services will apply any necessary operating system
and security updates.
Will restarts result in downtime for apps with automatic scaling enabled? If so, are there any steps I can take to avoid downtime?
For example, I could frequently migrate traffic to new instances so that no instance runs for more than one week.
Well, Later I checked with the Google support team and here the recommendation from them to avoid the downtime.
My questions are:
The weekly update is not fixed in time. Maybe there is a range in time in which I should expect the reboot of the instances? (ie: every Friday during the night).
The weekly update involves all the instances, independently from when they were created? (ie: an instance created 1 hour or 1 day before the weekly update will be restarted?).
How do we suppose to handle such a problem? it returns 502 for all request in the meantime.
1.- At this moment there is no way to know when the weekly restart is going to happen. GCP determine when is necessary and it does the restart of certain instances (once per week).
2.- No, as long as you have more than 1 one instance running you won’t see all of them being restarted at the same time.
3.- What we recommend to avoid downtime due to weekly restarts is having more than 1 instance as a minimum instance. Try to set at least 2 instances as a minimum.
I hope, this information is useful to others.
The answer to your question is in the docs:
App Engine attempts to keep manual scaling instances running indefinitely, but there is no uptime guarantee. Hardware or software failures that cause early termination or frequent restarts can occur without warning and can take considerable time to resolve. Your application should be able to handle such failures.
Here are some good strategies for avoiding downtime due to instance restarts:
Use load balancing across multiple instances.
Configure more instances than required to handle normal traffic.
Write fall-back logic that uses cached results when a manual scaling instance is unavailable.
Reduce the amount of time it takes for your instances to start up and shutdown.
Duplicate the state information across more than one instance.
For long-running computations, checkpoint the state from time to time so you can resume it if it doesn't complete.
I have a relatively low traffic app that can easily be handled by a single instance more than 95% of the time. Occasionally, having more than one instance running would be helpful to provide a better user experience.
It seems that GAE should be able to automatically scale in this way, but I can't get GAE to keep only a single instance when traffic is low. This is what I have tried:
Set min instances to 1
Set max instances to 3
Set min pending latency to 1 second
Set max pending latency to automatic (and also 1 second)
With this configuration, GAE will just about always run two instances even though one is sufficient.
I know I can set max instances to one, but I want to be able to automatically scale when I need it.
Is it possible to do what I want?
Note that the min/max property that you are setting are for IDLE instances.
Set min instances to 1 means that you will ALWAYS have at least one instance running, even when there are no requests for over 15 minutes. This could be set to 0 if you have low traffic AND your app launches quickly, i.e. under 1-2 seconds, otherwise the users will have bad experience with very slow response on their first request.
Set max instances to 3 means that it's OK for GAE to keep up to three instances running at any time, even when there are only few requests. This could be set to 1 to save some costs but would make some requests slow (time it takes to start new instance + time to launch your app) when traffic increases.
The max-idle-instances does not limit the number of instances in the event of a traffic spike, your app will always scale and new instances will keep launching if needed. The min/max settings are only there to help handle a sudden increase in traffic and there is no way to limit the number of instances that can be launched.
Take a look at this article for some more details: Setting the Number of Idle Instances
Regarding your question, you could try decreasing the max-idle-instances to 1 and see if that helps. You don't have to worry about scaling, new instances will still launch if needed, just keep in mind that the experience might not be as smooth for your users. If you decreased the number of max-idle-isntances and you still see more than 1 instance running on very low traffic, then your app might need to be optimized and multi-threading might need to be enabled if it wasn't.
There's something I really don't get about the new pricing. As far as I can see, I am now billed (amongst others) for the number of "instance/hours". On the other hand, a while back I've opted for the "Always on" feature, which since then effectively has 3 "Resident" instances of my application always running.
Now, A.F.A.I.C.S. , on the old pricing model, the one where I was charged by CPU Time used, the "always on" feature was great, not only did it made the app more responsive, but since the instances were no longer started-up/torn-down when traffic was scarce, the CPU Time was lowered (and indeed this is visible on the dashboard).
But now, since I'm billed by Instance/hours, the fact that I have this "always on" option active doesn't in fact add a lot of money to my bill, even when those instances are not actually doing anything (simply because they're just there, always on)?
I'm asking this because since the new pricing model was activated, I have whopping increase in Frontend Instance Hours (right now it's 29.21 for the last 9 hours), where before the CPU Time never really came close to depassing the free quota.
The "Always On" feature does not exist as of 1.6.0. The equivalent replacement is setting the Min Idle Instances slider to 3 (and leaving the Max Idle Instances at "Automatic") in your Application Settings in the Admin Console.
add a lot of money to my bill, even when those instances are not actually doing anything (simply because they're just there, always on)?add a lot of money to my bill, even when those instances are not actually doing anything ...
The problem is that they are doing something. They are occupying RAM. The new pricing model attempts to more accurately model the underlying costs to Google, or at least that's what they tell us. You can change how many instances are always on by going to the admin interface. If you aren't really using all 3, try going down to 2 or 1. If your traffic spikes, more instances will be started up. You can also set a value for how much latency you want users to endure before new instances are spun up.
The scheduler might be spinning up more than one instance to respond to threads.
Is this in Java? You could try to make it threaded, to make it more responsive to lower latency.
You could also tweak the scheduler parameters to discourage it from spinning up more instances.
I'm currently in the process of rewriting my java code to run it on Google App Engine. Since I cannot use Timer for programming timeouts (no thread creation allowed), I need to rely on system clock to mark the time of the timeout start so that I could compare it later in order to find out if the timeout has occurred.
Now, several people (even on Google payroll) have advised developers not to rely on system time due to the distributed nature of Google app servers and not being able to keep their clocks in sync. Some say the deviance of system clocks can be up to 10s or even more.
1s deviance would be very good for my app, 2 seconds can be tolerable, anything higher than that would cause a lot of grief for me and my app users, but 10 second difference would turn my app effectively unusable.
I don't know if anything has changed for the better since then (I hope yes), but if not, then what are my options other than shooting up a new separate request so that its handler would sleep the duration of the timeout (which cannot exceed 30 seconds due to request timeout limitation) in order to keep the timeout duration consistent.
Thanks!
More Specifically:
I'm trying to develop a poker game server, but for those who are not familiar how online poker works: I have a set of players attached to 1 game instance. Evey player has a certain amount of time to act before the timeout will occur so the next player can act. There is a countdown on each actor and every client has to see it. Only one player can act at a time. The timeout durations I need are 10s and 20s for now.
You should never be making your request handlers sleep or wait. App Engine will only automatically scale your app if request handlers complete in an average of 1000ms or less; deliberately waiting will ruin that. There's invariably a better option than sleeping/waiting - let us know what you're doing, and perhaps we can suggest one.